On Sat, Apr 13, 2002 at 02:05:56AM -0400, Zygo Blaxell wrote: > >You mean that just because there will be no packet loss (but only delays) > >the algorithms TCP uses will fail? What kind of algorithm is that? > > Well, yes, that is what I mean. Routers tell TCP that bandwidth is scarce > by dropping packets (or using the ECN bit, but PPP-over-SSH doesn't set > the ECN bit either).
Or with higher latency. > > To grossly oversimplify, TCP algorithms try to compute available bandwidth > by trying to use larger and larger amounts of bandwidth until a lost > packet is reported by the receiver. The loss of a packet is not reported by the receiver but detected by the sender itself (timer). > No lost packet = no bandwidth > discovery = high latency, wasted bandwidth, and less tolerance for real > packet losses in the SSH TCP connection. In addition to this, the SSH > connection's TCP connection is probably using the same algorithms itself, > which change all of the input variables for the algorithms at more or > less the same times that the tunneled TCP will be trying to measure them. Each TCP connection has its own set of variables which is not shared with the other instances. So, the underlaying TCP (SSH) might have different window-size, timer-value and for that matter even different heuristics than the encapsulated TCP riding on top of it, completely independent. > No matter what the algorithms, if the delays accumulate enough, TCP > will eventually fail due to timeout. Since PPP over SSH cannot drop or > re-order packets, delay accumulation will continue as long as there is > continuous traffic on the PPP connection and the tunneled TCP window > size limit has not been reached. This phenomenon can go on until the RTT of the encapsulated TCP is slightly larger than the RTT of the underlaying TCP. At this time they should stabilize. This delta is proportional to the SSH and PPP overhead. > These effects can be mitigated somewhat using QoS to force packet loss > at the PPP interface, so that packet transmission levels are kept low > enough that this delay accumulation never happens. > > Additional problems occur if there are TCP retransmits inside the tunnel > (e.g. because the SSH session stalled). If you get more than a few > stalls within a minute, the SSH buffers will fill up with retransmitted > TCP packets, so your latency goes up and your efficiency goes down at > the same time! Again, if the reason for the stalled SSH is because of the underlaying TCP then both RTT's will increase accordingly. > The failure modes are: Case (2) and (3) are being considered as bugs or, for that matter, as deficiency/shortcomings and case (1) and (4) would affect both TCP sessions. Ramin > > - steadily increasing latency when bandwidth is in use, up to > about 120 seconds > > - SSH blocks on input or output and it hangs. Some SSH versions > have fixed this problem. > > - SSH or PPP protocol timeout (trivially easy to avoid) > > - TCP timeout (75 second delay * 9 retransmits = TCP connection > fails, IIRC) > > >And > >what happens in the real world in an Ethernet (hub, not switch) environment > >where there is almost no packet loss with possible delays? Does the > >algorithm fail too? > > In the real world, on Ethernet, there are two cases: a) the sending > host eventually exceeds the bandwidth available, and packets do get lost, > or b) the sending host never manages to transmit packets faster than the > network and receiver can receive them. Ethernet hubs do not have queues, > so delay is bounded by the maximum number of collision retransmits. > Even switches, which do have queues, do not have enough memory to create a > delay more than a few ms. Large trees of switches and hubs do have both > variable delays and packet loss, but their TCP performance--their > performance of any kind for that matter--is already awful, so you've > lost nothing. In all these cases, the TCP algorithm works as intended. > > -- > Zygo Blaxell (Laptop) <[EMAIL PROTECTED]> > GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
