At 08:46 PM 1/26/99 , Phil Karn wrote:
>>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 feature has already been put into BSD4.4. You can use the 'route'
command with the sendpipe/recvpipe options to do exactly what you
explained. This is then stored with the per-route metrics; not the default
route of course. For direct routes TCP even "learns" the right
sendpipe/recvpipe and stores those values with the route and initializes
send/receiver socket buffers accordingly.
This approach has flaws, though.
- If you don't sit right at the bottleneck and you don't know the
bottlenecks speed it does not work.
- Which RTT do you guess to calculate the windows?
There are even companies http://www.packeteer.com/ who make money with this
trick by touching the window advertized by each TCP flow passing through
their box. I bet they won't be happy to see IPsec flows ;-)
>This is a *much* better approach than summarily dropping packets at
>the far end when the queue exceeds some fixed length. [...]
I agree, if you know your bottleneck this works very nice and is certainly
the optimal thing to do. But it is not generally applicable. RED/ECN does
the same job but is cleaner and works for the general case.
> With
>the strict queue length limit, things get very unstable when you have
>more active TCPs than there are queue slots
Agree. Still, the more buffer the more chance to have stale data that has
to drain before I get the next web page.
Why are you so concerned about packets dropped at your ISP? It happens
everywhere in the Internet - that's the rule of the game - and as long as
your pipe is full you shouldn't have to worry. I still think that 3-4
packets per modem on each side should work just fine. The 10 packets that
get stale by a click also made their way over the entire path for nothing.
>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.
I guess without explicit feedback from the network it should be impossible
for TCP to figure that out.
///Reiner
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST