Date: Thu, 19 Feb 1998 02:45:42 +0900 From: Kenjiro Cho <kjc@csl.sony.co.jp> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: eivind@yes.no, plm@xs4all.nl, freebsd-current@FreeBSD.ORG Subject: Re: ppp and RED Message-ID: <199802181745.CAA29510@hotaka.csl.sony.co.jp> In-Reply-To: Your message of "Wed, 18 Feb 1998 15:43:03 %2B0100." <199802181443.PAA02990@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi, I'm sure RED is a big win for a slow ppp link. In the current TCP, fast-recovery fails when multiple packets get dropped in a single window. RED at the bottleneck link considerablly reduces the chance of successive packet drop. Traffic traces are available to prove it. It's not a slow link, though. http://www.csl.sony.co.jp/person/kjc/red/perf.html --kj >>>>> On Wed, 18 Feb 1998 15:43:03 +0100 (MET), Luigi Rizzo said: >> As a followup to my previous message on ppp and RED: >> I believe, that RED will gain you nothing on a (slow, as they >> usually are) ppp link. >> Below I'll try to explain my perplexity (which is also due the the >> fact that i have never seen evaluations of how RED performs on slow >> links -- the various papers seem to concentrate on mbit links). >> Consider that the typical ppp link is at one end of a path, has >> very low bandwidth, and constitutes the bottleneck of the path. >> Now remember that if you don't have at least 4 pkts in flight, fast >> retransmit will not work and your throughput will be awful. >> On the other hand, on the above setting, all packets in flight will >> be queued at the ppp link, where you get most of the delay. This >> is much different from what happens on faster paths, where the >> transmission time (pkt_size/bw) is comparable or even smaller than >> the propagation delay, and you can hope to have some packets in >> the pipes, or buffered at intermediate routers. >> So, to sum up, you cannot(*) keep the queue too short (say less >> than 3-4slots per flow) or you'll get timeouts; on the other hand >> the total queue size is already limited (20 buffers ?) or the delay >> would be exceedingly high. >> (*) you could if you had a different congestion notification >> mechanism, like ECN bits or a lower threshold on fast rxmt. but tcp >> does not have these... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802181745.CAA29510>