On Thu, 24 Apr 2003, James Yonan wrote: > Actually, I was thinking more about the situation where people are forced to > tunnel IP over TCP, for whatever reason, when UDP is not an option. Since IP > is designed to transit over an unreliable physical layer, when you tunnel it > over TCP (a la vpnd or IP over ssh) you end up with this problem: > > http://sites.inka.de/sites/bigred/devel/tcp-tcp.html (see Stacking TCPs) > > The key issue here is that when you tunnel IP over TCP, that will usually mean > TCP over TCP. And this tends to break TCP's retransmission algorithm. As the > article above states: "The upper layer will queue up more retransmissions > faster than the lower layer can process them". > > So my idea is why not filter out the upper layer TCP retransmissions, and > synthesize the return ACKs so that the upper TCP layer doesn't begin the > exponential backing off of the retransmit timer that eventually will stall the > connection? This process would essentially strip the upper layer TCP of its
I think data volume (in flight or lost) is the issue, not stalls. Once an ACK of the outer layer is returned, the inner layer will implicitly also see an ACK (payload) which will then kick the data flow alive again. > reliability function, since now the lower TCP layer will provide that > function. This is not difficult to implement, since to OpenVPN, the upper > layer protocols are all simply byte streams flowing over the TUN pipe. They > can be filtered without resorting to raw sockets or any other such potentially > unportable constructs. Only that OpenVPN would have to parse the TCP protocol for IPv4 and IPv6. -- Matthias Andree
