In article <[EMAIL PROTECTED]>,
Ramin Alidousti <[EMAIL PROTECTED]> 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).
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. 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.
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.
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!
The failure modes are:
- 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
