>I can't agree to this. Imagine the following: you sit at your low bandwidth
>bottleneck link say 14.4 kbps and your generous ISP allocates say 10
>packets to your modem line and the PPP's even negotiate an MTU (MRU) of
>1500 bytes. Now you're surfing the Web and like always you are hopping from
>link to link. What is going to happen is that TCP will have filled the
>buffer with 10 x 1500 bytes at the end of each CA cycle which get stale by
>a "click". Now you first have to wait for 15 Kbytes to drain over 14.4 kbps
For many years I regularly accessed the net from home over a dialup
link, and I used a very simple and effective fix for this problem: I
simply lowered my local TCP receive windows so the remote senders
could never pile up too many packets on the far end send queue in the
first place. I also lowered my send windows so the same problem
wouldn't happen on my local send queue.
A slow dialup link tends to dominate the bandwidth-delay product of an
entire Internet path, so static window values worked pretty well.
This technique has been nicely generalized in Linux and other modern
OSes by allowing per-route TCP windows and MSSes. Sure, they don't
work if you're routing through the machine in question, but they work
well enough for the common case.
This is a *much* better approach than summarily dropping packets at
the far end when the queue exceeds some fixed length. For one thing,
my receive TCP window is under my direct control, unlike the
parameters in the dialup server on the other end of my link. Also, on
the occasion I needed to start up several simultaneous transfers (and
was willing to take the throughput hit on each one) I could do so
without worrying about excessive packet losses on the other end. With
the strict queue length limit, things get very unstable when you have
more active TCPs than there are queue slots because there are no
mechanisms in standard TCP to reduce a congestion window to less than
one packet, e.g., by introducing an intentional delay between receipt
of an ack and the sending of new data.
I do wish that TCP could figure out for itself how to avoid growing
very long queues. As far as I know nobody has come up with a really
good algorithm to do it in the absence of SQ, or preferably ECN.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST