From owner-freebsd-current Wed Feb 18 11:22:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16349 for freebsd-current-outgoing; Wed, 18 Feb 1998 11:22:12 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from inetfw.sonycsl.co.jp (inetfw.sonycsl.co.jp [203.137.129.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA16270 for ; Wed, 18 Feb 1998 11:22:02 -0800 (PST) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.8.5/3.5W) with ESMTP id CAA22666; Thu, 19 Feb 1998 02:45:59 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.8.4/3.3W3) with ESMTP id CAA29510; Thu, 19 Feb 1998 02:45:43 +0900 (JST) Message-Id: <199802181745.CAA29510@hotaka.csl.sony.co.jp> To: Luigi Rizzo cc: eivind@yes.no, plm@xs4all.nl, freebsd-current@FreeBSD.ORG Subject: Re: ppp and RED In-reply-to: Your message of "Wed, 18 Feb 1998 15:43:03 +0100." <199802181443.PAA02990@labinfo.iet.unipi.it> Date: Thu, 19 Feb 1998 02:45:42 +0900 From: Kenjiro Cho Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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