Date: Wed, 18 Feb 1998 18:05:09 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: kjc@csl.sony.co.jp (Kenjiro Cho) Cc: eivind@yes.no, plm@xs4all.nl, freebsd-current@FreeBSD.ORG Subject: Re: ppp and RED Message-ID: <199802181705.SAA03415@labinfo.iet.unipi.it> In-Reply-To: <199802181745.CAA29510@hotaka.csl.sony.co.jp> from "Kenjiro Cho" at Feb 19, 98 02:45:23 am
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 of course i might be plain wrong since i have not done specific experiments. i don't think these traces (or those in Sally's RED papers, or those in the FRED papers etc) are applicable to links 100..500 times slower. See my comments below on realistic queue sizes for slow links. On top of this, i believe that the RTT estimate has a hard time in tracking the large queueing delay, so that most of the timeout when the FIFO queue overflows is masked by queued data still flowing on the link. As a consequence, the effect of a restart is not that bad, and the link might almost keep streaming. In any case, since you are working on this, presumably, to test your ALTQ stuff, why don't you set up my dummynet stuff at the sink (or modify dummynet so that it intercepts all IP traffic, as opposed to TCP only as it does now) ? That would enable you to do some quick tests with artificial bandwidth limitations, probably valid even to very low values. Dummynet is at http://www.iet.unipi.it/~luigi/research.html Alternatively, would it be hard to make a quick test using ns ? > >> 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. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ 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?199802181705.SAA03415>