3 ms·

UDP (and datagrams in general) are not the only alternative to TCP-over-TCP. My sshuttle VPN uses TCP but avoids the TCP-over-TCP problem. https://github.com/

UDP (and datagrams in general) are not the only alternative to TCP-over-TCP. My sshuttle VPN uses TCP but avoids the TCP-over-TCP problem. https://github.com/apenwarr/sshuttle https://github.com/apenwarr/sshuttle

danudey 12y ago
Somewhat off-topic but sshuttle is super super cool, thanks so much for writing it.
seunosewa 12y ago
Please explain how it avoids TCP-over-TCP. It doesn't seem to me that multiplexing multiple TCP connections over a single TCP link avoids the problem.
- chubot 12y ago
  Why wouldn't it? There aren't 2 TCP stacks. There aren't 2 timers as described in the article. I think the burden of proof is on you.
- apenwarr 12y ago
  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.
  - throwaway41597 12y ago
    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?

danudey 12y ago

Somewhat off-topic but sshuttle is super super cool, thanks so much for writing it.

seunosewa 12y ago

Please explain how it avoids TCP-over-TCP. It doesn't seem to me that multiplexing multiple TCP connections over a single TCP link avoids the problem.

chubot 12y ago
Why wouldn't it? There aren't 2 TCP stacks. There aren't 2 timers as described in the article. I think the burden of proof is on you.
apenwarr 12y ago
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.
- throwaway41597 12y ago
  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?