From owner-freebsd-current Wed Feb 18 08:10:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04052 for freebsd-current-outgoing; Wed, 18 Feb 1998 08:10:37 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA04038 for ; Wed, 18 Feb 1998 08:10:26 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA02990; Wed, 18 Feb 1998 15:43:03 +0100 From: Luigi Rizzo Message-Id: <199802181443.PAA02990@labinfo.iet.unipi.it> Subject: ppp and RED To: eivind@yes.no, plm@xs4all.nl, freebsd-current@FreeBSD.ORG Date: Wed, 18 Feb 1998 15:43:03 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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... 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