News for hackers. Stuff that matters.

A comment on Why TCP Over TCP Is a Bad Idea (2001). Parent comment

Re:Why TCP Over TCP Is a Bad Idea (2001) by apenwarr on Sunday March 29, 2015 @03:41PM (#9286189)
TCP congestion control fundamentally depends on packet loss to know when to slow down. If the outer TCP makes sure packet loss doesn't happen - because if it does, it retransmits - then the inner TCP won't know what's going on, and will send as fast as it can, creating a mess.

The trick with sshuttle is that you terminate the TCP sessions at the server, and just send the raw data over the multiplexed link; there are no inner TCP headers anymore. Then you add them back at the other end by reconstructing a new TCP session. This eliminates the second layer of TCP congestion control inside the tunnel.

[ Parent | on HN ]
Re:Why TCP Over TCP Is a Bad Idea (2001) by throwaway41597 on Sunday March 29, 2015 @05:57PM (#9286631)
I'm not totally sure I understand correctly:

1) a TCP packet from source IP S comes in on side A of your tunnel

2) instead of acknowledging the packet, side A only sends it as data to side B other TCP (ssh)

3) the data may get lost, in which case, the TCP connection between A and B retransmits

4) side B gets the data, forwards the packet to the destination IP D

5) D acknowledges, sends a packet to S

S --------- A ================= B ------------ D

When there is a lot of packet loss at step 3, the delay before S getting the acknowledgement sent at step 5 increases and S sees the congestion. Unlike TCP-over-TCP where A acknowledges packets from S as soon as it gets them.

Is that right?

[ Parent | on HN ]