At 12:14 AM 1/22/99 , Phil Karn wrote:
>>Right, that's why ISP's should (and some do) configure their dial-up lines
>>to not allocate more than 3-4 packets per modem. For the same reason
>>wireless hosts which usually don't have to many flows active and sending at
>>the same time should also not have a much bigger interface buffer.
>
>I know this is a common practice, but it's always bothered me. I just
>don't like the notion of a node deliberately dropping a packet when it
>doesn't really have to. It means periodic packet drops and end-to-end
>retransmissions whenever the congestion window exceeds the buffer
>limit. These may not affect the throughput of the link in question,
>but it does affect the efficiency of the rest of the Internet. People
>complain about the added load of ICMP Source Quench messages, but
>surely the occasional small SQ message is a lot less overhead than the
>big data packet that has to be retransmitted because of an intentional drop
>at a bottleneck link.
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
+ if your browser sets up a new TCP connection the initial SYN of that
connection is guaranteed to not make it.
Says: you want to have your TCP always fill the pipe capacity but not the
bottleneck buffer (which together make up the bandwidthxdelay product). You
want to have a little bit of buffer to cover transients, though - more than
just one packet of buffer. A packet drop at the end of each congestion
avoidance (CA) cycle is just part of the game - until we all do ECN of
course. Thus, I don't want my ISP to allocate more than 3-4 packets to my
modem. I would change the ISP otherwise. That's also why RED makes a lot of
sense. Allocating only 3-4 packets per modem line is just the simplest
implementation of it.
Concerning the argument around SQ the question then becomes the trade-off
between either sending an SQ message (which can easily get dropped itself)
per CA cycle or to drop a packet per cycle. Because of that I also do not
see much need for the SQ. A piggy-backed ECN bit is much cleaner.
///Reiner
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST