3 ms·

I think it would be possible to avoid this issue by acking the inner TCP packets on the send end of the tunnel. This way the sending application believes that t

I think it would be possible to avoid this issue by acking the inner TCP packets on the send end of the tunnel. This way the sending application believes that the package has been sent successfully. Because the outer TCP will ensure reliable delivery there should never be a need to retransmit a packet for the inner TCP.

VLM 6y ago
A proxy server, essentially.
- kevincox 6y ago
  Essentially yes. You are terminating one TCP connection. Shuffling the data stream over your tunnel however you want and establishing another TCP connection at the other end. The only real difference is that the source and destination address isn't changed.
  - deleted 6y ago
    [deleted]
  - gray_-_wolf 6y ago
    Would this not have the chance of breaking anything relying on tcp keepalives?
dhdhhdd 6y ago
That breaks your bandwidth estimation though? So you're more likely to fill up your sending buffers and then suddenly stall anyway
- dTal 6y ago
  You would ACK after a suitable delay, to throttle the inner connection to a level where your sending buffers don't fill up.