Archives up to June 5, 2001: --------------------------- >From floyd@owl.ee.lbl.gov Mon Dec 21 10:44:08 1998 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA11046 for ; Mon, 21 Dec 1998 10:44:08 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA24385 for ; Mon, 21 Dec 1998 10:44:07 -0800 (PST) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA24375 for ; Mon, 21 Dec 1998 10:44:05 -0800 (PST) Received: (from floyd@localhost) by owl.ee.lbl.gov (8.9.1/8.9.1) id KAA05203; Mon, 21 Dec 1998 10:44:05 -0800 (PST) Message-Id: <199812211844.KAA05203@owl.ee.lbl.gov> To: red-impl@lbl.gov Subject: testing new red-implementors mailing list Date: Mon, 21 Dec 1998 10:44:05 PST From: Sally Floyd This is a test for the new red-implementors mailing list, that at the moment only has two members. Assuming that this message works, I will put a pointer on the RED web page, and send an announcement to the end2end-interest mailing list. - Sally >From floyd@owl.ee.lbl.gov Mon Dec 21 16:03:30 1998 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA14870 for ; Mon, 21 Dec 1998 16:03:29 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA20889 for ; Mon, 21 Dec 1998 16:03:28 -0800 (PST) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA20840 for ; Mon, 21 Dec 1998 16:03:25 -0800 (PST) Received: (from floyd@localhost) by owl.ee.lbl.gov (8.9.1/8.9.1) id QAA05818; Mon, 21 Dec 1998 16:02:06 -0800 (PST) Message-Id: <199812220002.QAA05818@owl.ee.lbl.gov> To: red-impl@lbl.gov Subject: Welcome to red-impl@lbl.gov Date: Mon, 21 Dec 1998 16:02:06 PST From: Sally Floyd You have been added to the red-implementors mailing list, at "red-impl@lbl.gov". This list is at the request of an implementor, and is intended for people implementing RED in hardware or in software (or thinking about implementing RED, or even just interested in discussions of RED implementations) to talk among themselves. - Sally -------------------------------- http://www-nrg.ee.lbl.gov/floyd/ -------------------------------- >From floyd@owl.ee.lbl.gov Mon Dec 21 17:48:18 1998 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id RAA15673 for ; Mon, 21 Dec 1998 17:48:18 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id RAA09462 for ; Mon, 21 Dec 1998 17:48:17 -0800 (PST) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id RAA09458 for ; Mon, 21 Dec 1998 17:48:17 -0800 (PST) Received: (from floyd@localhost) by owl.ee.lbl.gov (8.9.1/8.9.1) id RAA06056; Mon, 21 Dec 1998 17:48:16 -0800 (PST) Message-Id: <199812220148.RAA06056@owl.ee.lbl.gov> To: red-impl@lbl.gov Subject: subscribing and unsubscribing from the red-impl mailing list Date: Mon, 21 Dec 1998 17:48:16 PST From: Sally Floyd If you received this message, you are now on the red-impl mailing list. People not on this mailing list can now add themselves by sending email to "red-impl-request@lbl.gov" with subject "subscribe". You can unsubscribe by sending email to "red-impl-request@lbl.gov" with subject "unsubscribe". - Sally >From chetansk@wipinfo.soft.net Thu Dec 31 22:15:13 1998 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id WAA19324 for ; Thu, 31 Dec 1998 22:15:11 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id WAA10190 for ; Thu, 31 Dec 1998 22:15:10 -0800 (PST) Received: from wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by SpamWall.lbl.gov (8.9.0/8.9.0) with SMTP id WAA10172 for ; Thu, 31 Dec 1998 22:15:01 -0800 (PST) Received: from wipro.tcpn.com by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id LAA04015; Fri, 1 Jan 1999 11:38:25 -0500 Received: from mohanam.wipro.tcpn.com (chetansk@mohanam.wipro.tcpn.com [172.31.41.27]) by wipro.tcpn.com (8.8.5/8.8.5) with ESMTP id LAA15746 for ; Fri, 1 Jan 1999 11:48:48 +0530 (IST) Received: from localhost (chetansk@localhost) by mohanam.wipro.tcpn.com (8.8.5/8.8.5) with SMTP id LAA04478 for ; Fri, 1 Jan 1999 11:51:31 +0530 X-Authentication-Warning: mohanam.wipro.tcpn.com: chetansk owned process doing -bs Date: Fri, 1 Jan 1999 11:51:30 +0530 (IST) From: S Chetan Kumar X-Sender: chetansk@mohanam.wipro.tcpn.com To: red-impl@lbl.gov Subject: pointers to optimal value of min-th ?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Is there any paper that relate the min-th (minimum threshold) to network characterstic like bandwidth and delay and characterstic of the connection, such as playback time of a real time traffic, a time sensitive traffic, a bulky traffic and etc.. --Chetan S >From floyd@owl.ee.lbl.gov Fri Jan 1 16:30:01 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA20062 for ; Fri, 1 Jan 1999 16:30:00 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA11011 for ; Fri, 1 Jan 1999 16:29:59 -0800 (PST) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA11007 for ; Fri, 1 Jan 1999 16:29:58 -0800 (PST) Received: (from floyd@localhost) by owl.ee.lbl.gov (8.9.1/8.9.1) id QAA12603; Fri, 1 Jan 1999 16:29:43 -0800 (PST) Message-Id: <199901020029.QAA12603@owl.ee.lbl.gov> To: S Chetan Kumar cc: red-impl@lbl.gov Subject: Re: pointers to optimal value of min-th ?? Date: Fri, 01 Jan 1999 16:29:43 PST From: Sally Floyd Chetan - > Is there any paper that relate the min-th (minimum threshold) to >network characterstic like bandwidth and delay and characterstic of the >connection, such as playback time of a real time traffic, a time sensitive >traffic, a bulky traffic and etc.. There are a number of papers (unrelated to RED) that discuss the optimal average queue size for optimizing network power (or some other function of bandwidth and delay), given a particular set of assumptions about the aggregate traffic. I don't know off-hand of any papers that do this in the specific context of RED. To the best of my knowledge, the question of the optimal average queue size for aggregate Internet traffic (with its per-flow end-to-end congestion control) is largely an open question. - Sally >From chetansk@wipinfo.soft.net Mon Jan 4 20:32:20 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA07685 for ; Mon, 4 Jan 1999 20:32:18 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA10982 for ; Mon, 4 Jan 1999 20:32:17 -0800 (PST) Received: from wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by SpamWall.lbl.gov (8.9.0/8.9.0) with SMTP id UAA10975 for ; Mon, 4 Jan 1999 20:32:13 -0800 (PST) Received: from wipro.tcpn.com by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id JAA00762; Tue, 5 Jan 1999 09:55:13 -0500 Received: from mohanam.wipro.tcpn.com (chetansk@mohanam.wipro.tcpn.com [172.31.41.27]) by wipro.tcpn.com (8.8.5/8.8.5) with ESMTP id KAA03459; Tue, 5 Jan 1999 10:05:41 +0530 (IST) Received: from localhost (chetansk@localhost) by mohanam.wipro.tcpn.com (8.8.5/8.8.5) with SMTP id KAA02356; Tue, 5 Jan 1999 10:08:53 +0530 X-Authentication-Warning: mohanam.wipro.tcpn.com: chetansk owned process doing -bs Date: Tue, 5 Jan 1999 10:08:53 +0530 (IST) From: S Chetan Kumar X-Sender: chetansk@mohanam.wipro.tcpn.com To: Sally Floyd cc: red-impl@lbl.gov Subject: Re: pointers to optimal value of min-th ?? In-Reply-To: <199901020029.QAA12603@owl.ee.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Jan 1999, Sally Floyd wrote: > Chetan - I really thank for your reply. I appreciate if you could send me a list of papers that that discuss the optimal average queue size for optimizing network power (either not related to RED or otherwise). As I am looking at a CBQ implentation with RED gateway type congestion control for each class, some knowledge on ave que length relating the network power would be a much helpful for me. Thanks --Chetan S > > There are a number of papers (unrelated to RED) that discuss the > optimal average queue size for optimizing network power (or some other > function of bandwidth and delay), given a particular set of assumptions > about the aggregate traffic. I don't know off-hand of any papers that > do this in the specific context of RED. To the best of my knowledge, > the question of the optimal average queue size for aggregate > Internet traffic (with its per-flow end-to-end congestion control) > is largely an open question. > > - Sally >From chetansk@wipinfo.soft.net Tue Jan 5 19:24:05 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id TAA13597 for ; Tue, 5 Jan 1999 19:24:03 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id TAA05095 for ; Tue, 5 Jan 1999 19:24:02 -0800 (PST) Received: from wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by SpamWall.lbl.gov (8.9.0/8.9.0) with SMTP id TAA05086 for ; Tue, 5 Jan 1999 19:23:58 -0800 (PST) Received: from wipro.tcpn.com by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id IAA04983; Wed, 6 Jan 1999 08:47:03 -0500 Received: from mohanam.wipro.tcpn.com (chetansk@mohanam.wipro.tcpn.com [172.31.41.27]) by wipro.tcpn.com (8.8.5/8.8.5) with ESMTP id IAA18536; Wed, 6 Jan 1999 08:57:32 +0530 (IST) Received: from localhost (chetansk@localhost) by mohanam.wipro.tcpn.com (8.8.5/8.8.5) with SMTP id JAA04748; Wed, 6 Jan 1999 09:00:16 +0530 X-Authentication-Warning: mohanam.wipro.tcpn.com: chetansk owned process doing -bs Date: Wed, 6 Jan 1999 09:00:16 +0530 (IST) From: S Chetan Kumar X-Sender: chetansk@mohanam.wipro.tcpn.com To: Sally Floyd cc: red-impl@lbl.gov Subject: Re: pointers to optimal value of min-th ?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My apologies if this is duplicate, I was wondering if this mail had stuck up in postpone folder. On Fri, 1 Jan 1999, Sally Floyd wrote: > Chetan - I really thank for your reply. I appreciate if you could send me a list of papers that that discuss the optimal average queue size for optimizing network power (either not related to RED or otherwise). As I am looking at a CBQ implentation with RED gateway type congestion control for each class, some knowledge on ave que length relating the network power would be a much helpful for me. Thanks --Chetan S > > There are a number of papers (unrelated to RED) that discuss the > optimal average queue size for optimizing network power (or some other > function of bandwidth and delay), given a particular set of assumptions > about the aggregate traffic. I don't know off-hand of any papers that > do this in the specific context of RED. To the best of my knowledge, > the question of the optimal average queue size for aggregate > Internet traffic (with its per-flow end-to-end congestion control) > is largely an open question. > > - Sally >From floyd@owl.ee.lbl.gov Wed Jan 6 11:06:10 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id LAA15760 for ; Wed, 6 Jan 1999 11:06:10 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id LAA10029 for ; Wed, 6 Jan 1999 11:06:08 -0800 (PST) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id LAA09999 for ; Wed, 6 Jan 1999 11:06:06 -0800 (PST) Received: (from floyd@localhost) by owl.ee.lbl.gov (8.9.2/8.9.2) id LAA15423; Wed, 6 Jan 1999 11:05:45 -0800 (PST) Message-Id: <199901061905.LAA15423@owl.ee.lbl.gov> To: S Chetan Kumar cc: red-impl@lbl.gov Subject: Re: pointers to optimal value of min-th ?? Date: Wed, 06 Jan 1999 11:05:45 PST From: Sally Floyd >I really thank for your reply. I appreciate if you could send me a list of >papers that that discuss the optimal average queue size for optimizing >network power (either not related to RED or otherwise). One paper (not related to RED) is the following: Asymptotically Optimal Design of Congestion Control for High Speed Data Networks, D. Mitra, IEEE Trans. Communication, 40:2 (1992), pp. 301-311. This paper considers a virtual circuit with a single flow, with an adaptive window. The main result is that, given a delay-bandwidth product L, power (i.e., throughput/roundtrip time) is optimized when the window is L + O(sqrt(L)) and the mean queue size is O(sqrt(L)). (Where the O() notation is about the asymptotic behavior.) The analysis assumes Poisson cross traffic, and allows either round robin scheduling, or FIFO scheduling with exponential service times. (The Mitra paper not intended to accomodate the buffer requirements of TCP's current slow-start algorithm. A SIGCOMM 90 paper by Mitra and Seery uses this result to design an end-to-end congestion control scheme where the window is adapted as a result of the measured roundtrip time.) I don't recall off-hand if there is an analytical or experimental paper exploring optimal queue sizes for aggregate traffic that is fractal, composed of many flows each of which uses end-to-end congestion control. I would assume that the optimal queue size for the aggregate traffic in a FIFO queue would be dependent on the "burstiness" of the aggregate traffic, which is itself a function of both the degree of statistical multiplexing and on the "burstiness" of an individual flow. (Even with self-similar aggregate traffic, the *variance* of the arrival rate is a function of the degree of statistical multiplexing.) I assume that, instead of having a fixed minthresh and maxthresh and a function giving the packet drop probability as a linear function of the average queue size, more advanced active queue management mechanisms could try to maintain an average queue size that directly optimizes some function of the measured throughput and average queueing delay. Fortunately, this would not necessarily require analytical understandings of the current traffic characteristics or of the optimal average queue size for that traffic type. - Sally >From parris@cs.unc.edu Sun Jan 10 16:22:12 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA01494 for ; Sun, 10 Jan 1999 16:22:12 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA18338 for ; Sun, 10 Jan 1999 16:22:11 -0800 (PST) Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA18332 for ; Sun, 10 Jan 1999 16:22:07 -0800 (PST) Received: from eagle.cs.unc.edu (eagle.cs.unc.edu [152.2.128.10]) by austin.cs.unc.edu (8.8.8/8.8.8) with ESMTP id TAA05101; Sun, 10 Jan 1999 19:22:04 -0500 (EST) Received: (from parris@localhost) by eagle.cs.unc.edu (8.8.8/8.8.8) id TAA22301; Sun, 10 Jan 1999 19:22:01 -0500 (EST) Date: Sun, 10 Jan 1999 19:22:01 -0500 (EST) From: Mark Parris Message-Id: <199901110022.TAA22301@eagle.cs.unc.edu> To: red-impl@lbl.gov Subject: Promoting the Use of End-to-End Congestion Control Cc: parris@cs.unc.edu I'm doing some work on active queue management and would like to know if there has been any follow-up work on "Promoting the Use of End-to-End Congestion Control in the Internet" (Floyd & Fall 98). Also, is this the work folks are generally referring to when they talk about RED with penalty boxes? Thanks, Mark Parris >From dovrolis@hertz.ece.wisc.edu Fri Jan 22 08:05:02 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA29226 for ; Fri, 22 Jan 1999 08:05:01 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA06221 for ; Fri, 22 Jan 1999 08:05:00 -0800 (PST) Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA06208 for ; Fri, 22 Jan 1999 08:04:58 -0800 (PST) Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) with SMTP id KAA01457 for ; Fri, 22 Jan 1999 10:03:56 -0600 (CST) Message-Id: <199901221603.KAA01457@hertz.ece.wisc.edu> Date: Fri, 22 Jan 1999 10:03:56 -0600 (CST) From: Constantinos Reply-To: Constantinos Subject: RED in hardware To: red-impl@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SU9T4r9KKQzB+Ar0YF/ZpQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Hi RED-folks, I take a course this semester in which we will implement a large system in hardware. The technology is using 6 FPGAs (with 30000 to 40000 usable gates) and a bunch of SRAM. The system cannot run in high speeds (usually they run at less than 10 MHz) because of the wirewrap technology that is used. Anyway, we plan to implement a "down-scaled" forwarding engine, and one of the modules that we will build is RED. I would like to know from the people in this list anything related with the following: 1. Are there any hardware implementations of RED? Are there any publicly available documentations? 2. Which are the major issues in implementing RED in hardware? I mean, would people implement the algorithm in any different way if it would be in silicon, rather than software? 3. Are there are any ideas/suggestions regarding RED that you would like us to examine in the implementation? The project cannot provide any useful information on the maximum possible speed in which an algorithm can be implemented (as I said, it is < 10MHz). It can provide though rough estimates on the # of gates and some insight in the complexity issues. Thanks a lot in advance for any suggestions, Constantinos >From Yoichi.Hariguchi@mayannetworks.com Mon Jan 25 13:42:40 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA12209 for ; Mon, 25 Jan 1999 13:42:40 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA08169 for ; Mon, 25 Jan 1999 13:42:39 -0800 (PST) Received: from hairball.mayannetworks.com (h253.mayan-net.com [206.184.145.253]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA08160 for ; Mon, 25 Jan 1999 13:42:38 -0800 (PST) Received: from localhost (yoichi@dhcp-90.mayannetworks.com [192.168.1.90]) by hairball.mayannetworks.com (8.8.8/8.8.8) with ESMTP id NAA15232 for ; Mon, 25 Jan 1999 13:41:57 -0800 (PST) To: red-impl@lbl.gov Subject: RED in background task X-Mailer: Mew version 1.92 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990125134141E.yoichi@mayannetworks.com> Date: Mon, 25 Jan 1999 13:41:41 -0800 From: Yoichi Hariguchi X-Dispatcher: imput version 971024 Lines: 35 Dear members, I am going to implement the RED as a background task. I think basically what I have to do is: calculating the packet marking probability Pa based on not per packet base but per sampling time base. Is it correct? I also read the following presentation by Mr. Van Jacobson: http://www.nanog.org/mtg-9806/ppt/vj-nanog-red.pdf In slide 12 of this presentation, he says: RED requires exactly one addition to the forwarding path (in the place where an arriving packet is added to the queue): if (-- packetsTillDrop == 0) DropPacket(); I do not understand to what parameter in the original RED paper the 'packetsTillDrop' variable is related. I would appreciate it if somebody here could tell me how to calculate the value of 'packetsTillDrop' in his presentation. Thanks in advance, Yoichi Hariguchi >From tli@juniper.net Mon Jan 25 15:49:47 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id PAA12439 for ; Mon, 25 Jan 1999 15:49:47 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id PAA15829 for ; Mon, 25 Jan 1999 15:49:46 -0800 (PST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id PAA15823 for ; Mon, 25 Jan 1999 15:49:45 -0800 (PST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id PAA23905; Mon, 25 Jan 1999 15:49:10 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.8.8/8.7.3) id XAA14874; Mon, 25 Jan 1999 23:49:10 GMT Date: Mon, 25 Jan 1999 23:49:10 GMT Message-Id: <199901252349.XAA14874@chimp.juniper.net> From: Tony Li To: Yoichi.Hariguchi@mayannetworks.com CC: red-impl@lbl.gov In-reply-to: <19990125134141E.yoichi@mayannetworks.com> (message from Yoichi Hariguchi on Mon, 25 Jan 1999 13:41:41 -0800) Subject: Re: RED in background task | I am going to implement the RED as a background task. I think | basically what I have to do is: | | calculating the packet marking probability Pa | based on not per packet base but per sampling time base. | | | Is it correct? IMHO, no. The problem with computing the probability periodically is that the probability needs to be computed per input packet. The queue length can be averaged periodically. | I also read the following presentation by Mr. Van Jacobson: | | http://www.nanog.org/mtg-9806/ppt/vj-nanog-red.pdf | | In slide 12 of this presentation, he says: | | RED requires exactly one addition to the forwarding path (in | the place where an arriving packet is added to the queue): | | if (-- packetsTillDrop == 0) | DropPacket(); | | | I do not understand to what parameter in the original RED paper | the 'packetsTillDrop' variable is related. I would appreciate | it if somebody here could tell me how to calculate the value of | 'packetsTillDrop' in his presentation. | As I recall (it's been a while), after Van determined to do a drop, he selected a random number to actually perform the drop. Tony >From metin@us.ibm.com Tue Jan 26 09:02:10 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id JAA14376 for ; Tue, 26 Jan 1999 09:02:10 -0800 (PST) From: metin@us.ibm.com Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id JAA01545 for ; Tue, 26 Jan 1999 09:02:09 -0800 (PST) Received: from smtp4.server.ibm.com (smtp4.ny.us.ibm.com [198.133.22.43]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id JAA01537 for ; Tue, 26 Jan 1999 09:02:08 -0800 (PST) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by smtp4.server.ibm.com (8.8.7/8.8.7) with ESMTP id LAA66576 for ; Tue, 26 Jan 1999 11:47:13 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay01.raleigh.ibm.com (8.8.7/NCO v1.8) with SMTP id MAA45642 for ; Tue, 26 Jan 1999 12:01:34 -0500 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256705.005D8390 ; Tue, 26 Jan 1999 12:01:25 -0500 X-Lotus-FromDomain: IBMUS To: red-impl@lbl.gov Message-ID: <85256705.005D7F9E.00@d54mta03.raleigh.ibm.com> Date: Tue, 26 Jan 1999 11:58:18 -0500 Subject: Re: RED in background task Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Here is my take for RED in background: When running RED as background task, the average queue size (avg) is calculated periodically. Then, you can calculate p_b (packet-marking probability) (using terms of 1993 Floyd and Jacobson RED paper). The p_b will be fixed for the period at hand. The actual drop decision can be done as defined in Section 7 and 11 of the RED paper (mentioned above). In short, the algorithm marks (i.e. drops) the n-th arriving packet where n >= R/p_b and R is the random number [0,1]). With this approach, the random number generation is needed only once for every marked packet. An interesting question is : What should be the period of the "avg" calculation? And related to this what should be the "w_q" (weight) value? Any ideas? Metin. Tony Li on 01/25/99 06:49:10 PM To: Yoichi.Hariguchi@mayannetworks.com cc: red-impl@lbl.gov (bcc: M Aydemir/Raleigh/IBM) Subject: Re: RED in background task | I am going to implement the RED as a background task. I think | basically what I have to do is: | | calculating the packet marking probability Pa | based on not per packet base but per sampling time base. | | | Is it correct? IMHO, no. The problem with computing the probability periodically is that the probability needs to be computed per input packet. The queue length can be averaged periodically. | I also read the following presentation by Mr. Van Jacobson: | | http://www.nanog.org/mtg-9806/ppt/vj-nanog-red.pdf | | In slide 12 of this presentation, he says: | | RED requires exactly one addition to the forwarding path (in | the place where an arriving packet is added to the queue): | | if (-- packetsTillDrop == 0) | DropPacket(); | | | I do not understand to what parameter in the original RED paper | the 'packetsTillDrop' variable is related. I would appreciate | it if somebody here could tell me how to calculate the value of | 'packetsTillDrop' in his presentation. | As I recall (it's been a while), after Van determined to do a drop, he selected a random number to actually perform the drop. Tony >From tli@juniper.net Tue Jan 26 13:18:16 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA16526 for ; Tue, 26 Jan 1999 13:18:16 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA20913 for ; Tue, 26 Jan 1999 13:18:15 -0800 (PST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA20909 for ; Tue, 26 Jan 1999 13:18:14 -0800 (PST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id NAA09376; Tue, 26 Jan 1999 13:17:43 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.8.8/8.7.3) id VAA19396; Tue, 26 Jan 1999 21:17:43 GMT Date: Tue, 26 Jan 1999 21:17:43 GMT Message-Id: <199901262117.VAA19396@chimp.juniper.net> From: Tony Li To: metin@us.ibm.com CC: red-impl@lbl.gov In-reply-to: <85256705.005D7F9E.00@d54mta03.raleigh.ibm.com> (metin@us.ibm.com) Subject: Re: RED in background task | An interesting question is : What should be the period of the "avg" | calculation? And related to this what should be the "w_q" (weight) value? | | Any ideas? Intuitively, it is not productive to calculate it more frequently than packets arrive. ;-) Further, you want the average to reflect a significant amount of history, so that you get a significant amount of damping. Recall that RED is the negative feedback in a control loop with a response time of RTT. Tony >From smb@research.att.com Wed Jan 27 18:34:49 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id SAA23062 for ; Wed, 27 Jan 1999 18:34:48 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id SAA00269 for ; Wed, 27 Jan 1999 18:34:44 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id SAA00259 for ; Wed, 27 Jan 1999 18:34:42 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 7F7F04CE0A; Wed, 27 Jan 1999 21:34:42 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id VAA16109; Wed, 27 Jan 1999 21:34:38 -0500 (EST) Received: from smb.research.att.com (smb@localhost) by smb.research.att.com (8.8.5/8.8.5) with ESMTP id VAA03373; Wed, 27 Jan 1999 21:34:37 -0500 (EST) Message-Id: <199901280234.VAA03373@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 From: Steve Bellovin To: ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@baynetworks.com, ecn-interest@research.att.com, red-impl@lbl.gov Subject: transport-friendly ESP Cc: jis@mit.edu, mleech@nortel.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jan 1999 21:34:35 -0500 Sender: smb@research.att.com I've set up a new mailing list, tf-esp@research.att.com, to discuss the design of a transport-friendly variant of ESP (a core piece of IPSEC). Subscription is via majordomo@research.att.com. The problem is that ESP, by hiding all of the TCP (and UDP) headers, makes life difficult for other purposes, such as discerning flows, building firewalls, etc. Can we come up with a variant of ESP that -- optionally -- leaves some of the packet header in the clear? A strawman proposal can be found in http://www.research.att.com/~smb/talks/mesp .ps or http://www.research.att.com/~smb/talks/mesp.pdf (content is the same). It leaves an indicated amount of the prefix in the clear. It's reasonably efficient in both space and time. However, it is based on the tacit assumption that the prefix of the packet headers are the least significant from a security perspective -- is this true? Do we need a more complex format that permits individual fields or ranges to be in the clear? How do we prevent careless leakage of sensitive data? For example, if the TCP checksum is exposed, an enemy can read all one- and two-byte payloads. How is this negotiated? It can't be a simple length, since that doesn't take into account UDP vs. TCP, IP options, IPv6 headers, etc. Is there any need to permit controlled modifications to packets? If so, how do we protect against nasty changes? Apart from discussing these questions on the list, we need to decide if we want to hold a BoF in Minneapolis. If the answer is yes, we'd also need to write up a charter and select chairs, preferably one from the security area and one from the transport area. Nominations are hereby solicited. The output of an eventual tfesp working group would be two or three RFCs -- standards-track RFCs to define the new header, to define the additions to IKE to negotiate use of this modified format, and possibly an informational RFC setting out the rationale for the change -- and the security caveats that would attend its use. >From Alten@Home.Com Wed Jan 27 21:13:05 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id VAA23190 for ; Wed, 27 Jan 1999 21:13:04 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id VAA17309 for ; Wed, 27 Jan 1999 21:13:03 -0800 (PST) Received: from mail.rdc1.sfba.home.com (imail@ha1.rdc1.sfba.home.com [24.0.0.66]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id VAA17305 for ; Wed, 27 Jan 1999 21:13:03 -0800 (PST) Received: from alten_pc ([24.1.100.65]) by mail.rdc1.sfba.home.com (InterMail v4.00.03 201-229-104) with SMTP id <19990128051302.SAYI9535.mail.rdc1.sfba.home.com@alten_pc>; Wed, 27 Jan 1999 21:13:02 -0800 Message-Id: <3.0.3.32.19990127200721.00b553e0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 27 Jan 1999 20:07:21 -0800 To: Steve Bellovin , ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov From: Alex Alten Subject: Re: transport-friendly ESP Cc: jis@MIT.EDU, mleech@nortel.ca In-Reply-To: <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:34 PM 1/27/99 -0500, Steve Bellovin wrote: >I've set up a new mailing list, tf-esp@research.att.com, to discuss the >design of a transport-friendly variant of ESP (a core piece of IPSEC). >Subscription is via majordomo@research.att.com. > >The problem is that ESP, by hiding all of the TCP (and UDP) headers, makes >life difficult for other purposes, such as discerning flows, building >firewalls, etc. Can we come up with a variant of ESP that -- optionally -- >leaves some of the packet header in the clear? > Interesting. The end-to-end (e.g. host-to-host) nature of ESP conflicts with the need for intermediate nodes to access header information. Wouldn't it make more sense to let ESP secure per hop IP links? This way the transport headers are automatically decrypted coming into a node and re-encrypted exiting it. This allows firewall software, etc., to operate as-is. If one needs end-to-end security then TLS/SSL could then be layered on top. I know that that trusting intermediate nodes with clear IP packets in their RAM is a hard sell. But if TLS/SSL is being used to protect end-to-end user data payloads, why not just use ESP to protect the management and use of individual IP links? I.e. the routing packets, nearest neighbor discovery, etc., along with the datagrams (ICMP would need to handle its own end-to-end security). This would eliminate the need for doing transport-friendly ESP variants. - Alex -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 >From deering@cisco.com Wed Jan 27 21:57:35 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id VAA23208 for ; Wed, 27 Jan 1999 21:57:34 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id VAA20138 for ; Wed, 27 Jan 1999 21:57:34 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id VAA20134 for ; Wed, 27 Jan 1999 21:57:33 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA14810; Wed, 27 Jan 1999 21:55:50 -0800 (PST) X-Sender: deering@postoffice Message-Id: In-Reply-To: <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Jan 1999 21:56:03 -0800 To: Steve Bellovin From: Steve Deering Subject: Re: transport-friendly ESP Cc: ipsec@tis.com, end2end-interest@ISI.EDU, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@mit.edu, mleech@nortel.ca Gee, Steve, you oughta have a job in marketing. "Transport-friendly ESP" sounds great, compared to, say, "layer-violation-abetting ESP". Regular ol' ESP is plenty friendly to the transport layer, just not to those who want to snoop on or muck with the transport layer's headers in transit. Steve >From lixia@CS.UCLA.EDU Wed Jan 27 22:14:42 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id WAA23225 for ; Wed, 27 Jan 1999 22:14:41 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id WAA21209 for ; Wed, 27 Jan 1999 22:14:40 -0800 (PST) Received: from aurora.cs.ucla.edu (Aurora.CS.UCLA.EDU [131.179.96.157]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id WAA21205 for ; Wed, 27 Jan 1999 22:14:39 -0800 (PST) Received: (from lixia@localhost) by aurora.cs.ucla.edu (8.8.8+Sun/UCLACS-4.0) id WAA17897; Wed, 27 Jan 1999 22:14:25 -0800 (PST) From: Lixia Zhang Message-Id: <199901280614.WAA17897@aurora.cs.ucla.edu> Subject: Re: transport-friendly ESP To: deering@cisco.com (Steve Deering) Date: Wed, 27 Jan 1999 22:14:25 -0800 (PST) Cc: smb@research.att.com, ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@mit.edu, mleech@nortel.ca In-Reply-To: from "Steve Deering" at Jan 27, 99 09:56:03 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Gee, Steve, you oughta have a job in marketing. "Transport-friendly ESP" > sounds great, compared to, say, "layer-violation-abetting ESP". Regular > ol' ESP is plenty friendly to the transport layer, just not to those who > want to snoop on or muck with the transport layer's headers in transit. > > Steve although the above might not sound very "Steve-friendly":-), I somehow share the concern with opening up transport fields. So rather than taking the necessity as given (which I know has been stated/discussed many times), could some more informed parties help briefly re-iterate the needs for making ESP *more* transport-friendliness (than what it is now)? I remember hearing some sound reasons at the last TSV meeting but can't recall them all. If we see the list of reasons, then either Mr. Deering could be convinced, or maybe the list of reasons indeed deserves a revisit. Lixia >From mo@UU.NET Thu Jan 28 04:45:08 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id EAA23549 for ; Thu, 28 Jan 1999 04:45:08 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id EAA02970 for ; Thu, 28 Jan 1999 04:45:06 -0800 (PST) Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id EAA02966 for ; Thu, 28 Jan 1999 04:45:05 -0800 (PST) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQgaco07855; Thu, 28 Jan 1999 07:44:27 -0500 (EST) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQgaco27340; Thu, 28 Jan 1999 07:44:27 -0500 (EST) Message-Id: To: Steve Bellovin , ipsec@tis.com cc: Steve Deering , end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@mit.edu, mleech@nortel.ca Subject: Re: transport-friendly ESP In-reply-to: Your message of "Wed, 27 Jan 1999 21:56:03 PST." Date: Thu, 28 Jan 1999 07:44:27 -0500 From: "Mike O'Dell" why isn't the answer "just use TLS"??? a requirements doc which did a "compare and contrast" analysis would be interesting reading. if we had a nickel's worth of session layer in the APIs, this would be easy to insert even for apps which "don't know nothin'". moreover, a flyweight session mechanism would solve a bunch of other problems as well which people are addressing by inventing a zillion different new flat tires. so the recurring decision is... fix the architecture? hack yet more ugly cruft? fix the architecture? hack yet more ugly cruft? fix the architecture? hack yet more ugly cruft? to the casual observer, it sure seems like the second alternative has become "The DOH! of the IETF" -mo >From kasten@argon.com Thu Jan 28 05:52:23 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id FAA23708 for ; Thu, 28 Jan 1999 05:52:22 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id FAA07003 for ; Thu, 28 Jan 1999 05:52:22 -0800 (PST) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id FAA06991 for ; Thu, 28 Jan 1999 05:52:13 -0800 (PST) Received: from hochstetter (hochstetter.argon.com [208.234.161.53]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id IAA24952; Thu, 28 Jan 1999 08:50:08 -0500 (EST) Message-Id: <3.0.3.32.19990128085207.00977100@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 28 Jan 1999 08:52:07 -0500 To: Alex Alten , Steve Bellovin , ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov From: Frank Kastenholz Subject: Re: transport-friendly ESP Cc: jis@mit.edu, mleech@nortel.ca In-Reply-To: <3.0.3.32.19990127200721.00b553e0@mail> References: <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 08:07 PM 1/27/99 -0800, Alex Alten wrote: >Wouldn't >it make more sense to let ESP secure per hop IP links? No, No, No, and I say again, No. You don't want to have to distribute that keying information to routers that you may not trust. You don't want to have high speed-silicon-based-lifeforms in the core of the Internet have to grok the latest-encryption-algorithm-du-jour, process entire packets with said algorithm (including looking up more stuff to determine _which_ key to use) and have to be updated with new hardware every time a hyperadenoidal teenager cracks the l.e.a.d.j. Frank Kastenholz Silicon-Based-Lifeform-Foozler Argon Networks >From naganand@nortelnetworks.com Thu Jan 28 07:46:03 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA24490 for ; Thu, 28 Jan 1999 07:46:02 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA22220 for ; Thu, 28 Jan 1999 07:46:01 -0800 (PST) Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA22216 for ; Thu, 28 Jan 1999 07:46:01 -0800 (PST) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id HAA02969; Thu, 28 Jan 1999 07:42:09 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id HAA01782; Thu, 28 Jan 1999 07:44:22 -0800 (PST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-hme0.corpeast.baynetworks.com [132.245.135.82]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id KAA02462; Thu, 28 Jan 1999 10:44:18 -0500 for Received: from ndoraswa.corpeast.baynetworks.com ([192.32.214.139]) by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Thu, 28 Jan 1999 10:45:37 -0500 Message-Id: <3.0.32.19990128104213.00894cec@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 Jan 1999 10:42:14 -0500 To: Frank Kastenholz , Alex Alten , Steve Bellovin , ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov From: Naganand Doraswamy Subject: Re: transport-friendly ESP Cc: jis@mit.edu, mleech@nortel.ca Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 08:52 AM 1/28/99 -0500, Frank Kastenholz wrote: >At 08:07 PM 1/27/99 -0800, Alex Alten wrote: > >>Wouldn't >>it make more sense to let ESP secure per hop IP links? > I completly agree with Frank. Doing per hop decryption/encyrption should not even be an option. --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Internet Core Routers (978)916-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 >From dharkins@cisco.com Thu Jan 28 08:30:08 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA24672 for ; Thu, 28 Jan 1999 08:30:07 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA01777 for ; Thu, 28 Jan 1999 08:30:06 -0800 (PST) Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA01773 for ; Thu, 28 Jan 1999 08:30:06 -0800 (PST) Received: from dharkins-ss20.cisco.com (dharkins-ss20.cisco.com [171.71.39.35]) by rhine.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA16230; Thu, 28 Jan 1999 08:29:21 -0800 (PST) Received: from localhost (dharkins@localhost) by dharkins-ss20.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with SMTP id IAA05100; Thu, 28 Jan 1999 08:29:20 -0800 (PST) Message-Id: <199901281629.IAA05100@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: "Mike O'Dell" cc: Steve Bellovin , ipsec@tis.com, Steve Deering , end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Subject: Re: transport-friendly ESP In-reply-to: Your message of "Thu, 28 Jan 1999 07:44:27 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5098.917540960.1@cisco.com> Date: Thu, 28 Jan 1999 08:29:20 -0800 From: Daniel Harkins Because TLS is TCP-only and there's lots of stuff that goes on top of UDP. VoIP is a prime reason why not to use TLS (multicast is another) and a good reason why you'd want some sort of snooping/layer-violation. VoIP needs a higher quality of service than most anything else and service providers usually don't let you just set the TOS bits on packets you inject into their network. Dan. On Thu, 28 Jan 1999 07:44:27 EST you wrote > > why isn't the answer "just use TLS"??? > > a requirements doc which did a "compare and contrast" > analysis would be interesting reading. > > > > if we had a nickel's worth of session layer in the APIs, > this would be easy to insert even for apps which "don't > know nothin'". moreover, a flyweight session mechanism > would solve a bunch of other problems as well which people > are addressing by inventing a zillion different new flat > tires. > > so the recurring decision is... > > fix the architecture? hack yet more ugly cruft? > fix the architecture? hack yet more ugly cruft? > fix the architecture? hack yet more ugly cruft? > > to the casual observer, it sure seems like the > second alternative has become > > "The DOH! of the IETF" > > -mo > > > > >From smb@research.att.com Thu Jan 28 08:45:45 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA24693 for ; Thu, 28 Jan 1999 08:45:44 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA06208 for ; Thu, 28 Jan 1999 08:45:44 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA06204 for ; Thu, 28 Jan 1999 08:45:43 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 409264CE3D; Thu, 28 Jan 1999 11:45:42 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA02357; Thu, 28 Jan 1999 11:45:38 -0500 (EST) Received: from smb.research.att.com (smb@localhost) by smb.research.att.com (8.8.5/8.8.5) with ESMTP id LAA06988; Thu, 28 Jan 1999 11:45:34 -0500 (EST) Message-Id: <199901281645.LAA06988@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Daniel Harkins Subject: Re: transport-friendly ESP Cc: "Mike O'Dell" , ipsec@tis.com, Steve Deering , end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@baynetworks.com, ecn-interest@research.att.com, red-impl@lbl.gov, jis@mit.edu, mleech@nortel.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Jan 1999 11:45:32 -0500 From: "Steven M. Bellovin" Folks -- let's have this discussion on the tf-esp mailing list -- this message went to far too many places for this sort of argument. Whether or not we need this facility is certainly worth discussing, but I suspect I'm not the only one to see three or four copies of every reply... >From brian@hursley.ibm.com Thu Jan 28 10:44:05 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA25144 for ; Thu, 28 Jan 1999 10:44:04 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA12505 for ; Thu, 28 Jan 1999 10:44:03 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA12489 for ; Thu, 28 Jan 1999 10:44:01 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA33062; Thu, 28 Jan 1999 18:37:52 GMT Received: from hursley.ibm.com (lig32-225-78-206.us.lig-dial.ibm.com [32.225.78.206]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA14404; Thu, 28 Jan 1999 18:37:42 GMT Message-ID: <36B0967E.3DBF11C9@hursley.ibm.com> Date: Thu, 28 Jan 1999 16:55:26 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Steve Bellovin CC: ipsec@tis.com, end2end-interest@ISI.EDU, tsv@ee.lbl.gov, diff-serv@baynetworks.com, ecn-interest@research.att.com, red-impl@lbl.gov, jis@mit.edu, mleech@nortel.ca Subject: Re: transport-friendly ESP - use the dedicated list! References: <199901280234.VAA03373@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would really appreciate it if folks could take this thread to the list Steve has set up, rather than discuss it on 6 lists in parallel. Thanks Brian > I've set up a new mailing list, tf-esp@research.att.com, to discuss the > design of a transport-friendly variant of ESP (a core piece of IPSEC). > Subscription is via majordomo@research.att.com. > >From perry@piermont.com Fri Jan 29 12:26:46 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id MAA01355 for ; Fri, 29 Jan 1999 12:26:46 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id MAA11422 for ; Fri, 29 Jan 1999 12:26:44 -0800 (PST) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id MAA11407 for ; Fri, 29 Jan 1999 12:26:42 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id EE64A163; Fri, 29 Jan 1999 15:26:37 -0500 (EST) To: Lixia Zhang Cc: deering@cisco.com (Steve Deering), smb@research.att.com, ipsec@tis.com, end2end-interest@ISI.EDU, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@mit.edu, mleech@nortel.ca Subject: Re: transport-friendly ESP References: <199901280614.WAA17897@aurora.cs.ucla.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 29 Jan 1999 15:26:37 -0500 In-Reply-To: Lixia Zhang's message of "Wed, 27 Jan 1999 22:14:25 -0800 (PST)" Message-ID: <87ww25su4i.fsf@jekyll.piermont.com> Lines: 13 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Lixia Zhang writes: > > Gee, Steve, you oughta have a job in marketing. "Transport-friendly ESP" > > sounds great, compared to, say, "layer-violation-abetting ESP". Regular > > ol' ESP is plenty friendly to the transport layer, just not to those who > > want to snoop on or muck with the transport layer's headers in transit. > > although the above might not sound very "Steve-friendly":-), I somehow > share the concern with opening up transport fields. As do I, even though I'm generally a fan of Steve's. Perry >From kent@po1.bbn.com Sat Jan 30 12:18:22 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id MAA03306 for ; Sat, 30 Jan 1999 12:18:22 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id MAA16877 for ; Sat, 30 Jan 1999 12:18:21 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id MAA16873 for ; Sat, 30 Jan 1999 12:18:20 -0800 (PST) Received: from [128.33.238.94] (TC094.BBN.COM [128.33.238.94]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA14114; Sat, 30 Jan 1999 15:16:55 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <3.0.3.32.19990127200721.00b553e0@mail> References: <199901280234.VAA03373@smb.research.att.com> Date: Fri, 29 Jan 1999 15:55:41 -0500 To: Alex Alten From: Stephen Kent Subject: Re: transport-friendly ESP Cc: Steve Bellovin , ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Alex, The purpose of IPsec is to offer end-to-end protection, so applying IPsec on a per-hop basis is feasible, but findamentally counter to the underlying motivation for these protocols, since the begining of this work (too) many years ago. Steve >From tli@juniper.net Sat Jan 30 22:46:29 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id WAA03996 for ; Sat, 30 Jan 1999 22:46:29 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id WAA11149 for ; Sat, 30 Jan 1999 22:46:28 -0800 (PST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id WAA11145 for ; Sat, 30 Jan 1999 22:46:27 -0800 (PST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id WAA21909; Sat, 30 Jan 1999 22:44:45 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.8.8/8.7.3) id GAA06712; Sun, 31 Jan 1999 06:44:40 GMT Date: Sun, 31 Jan 1999 06:44:40 GMT Message-Id: <199901310644.GAA06712@chimp.juniper.net> From: Tony Li To: kent@bbn.com CC: Alten@home.com, smb@research.att.com, ipsec@tis.com, end2end-interest@ISI.EDU, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca In-reply-to: (message from Stephen Kent on Fri, 29 Jan 1999 15:55:41 -0500) Subject: Re: transport-friendly ESP Please, please, please, please... Take this thread off of every list except end2end-interest. Thanks, Tony | The purpose of IPsec is to offer end-to-end protection, so applying IPsec | on a per-hop basis is feasible, but findamentally counter to the underlying | motivation for these protocols, since the begining of this work (too) many | years ago. >From smb@research.att.com Tue Mar 9 07:21:44 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA12982 for ; Tue, 9 Mar 1999 07:21:43 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA14385 for ; Tue, 9 Mar 1999 07:21:43 -0800 (PST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA14381 for ; Tue, 9 Mar 1999 07:21:42 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 405FD1E013; Tue, 9 Mar 1999 10:21:37 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA06012; Tue, 9 Mar 1999 10:21:34 -0500 (EST) Received: by smb.research.att.com (Postfix, from userid 54047) id 40E8CACAA7; Tue, 9 Mar 1999 10:21:34 -0500 (EST) Received: from smb.research.att.com (localhost [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 1CE37ABBEB; Tue, 9 Mar 1999 10:21:29 -0500 (EST) From: Steve Bellovin To: ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@baynetworks.com, ecn-interest@research.att.com, red-impl@lbl.gov, tf-esp@research.att.com Subject: last call for tf-esp BoF speakers Reply-To: smb@research.att.com Cc: vern@ee.lbl.gov, sob@harvard.edu, jis@mit.edu, mleech@nortel.ca Date: Tue, 09 Mar 1999 10:21:28 -0500 Sender: smb@research.att.com Message-Id: <19990309152134.40E8CACAA7@smb.research.att.com> Please forgive the broad-spectrum mail -- I've set Reply-To to force responses to come to me, rather than to all of these lists. I'm still looking for speakers for the tf-esp BoF -- right now, it's marginal whether or not there are enough signed up to justify meeting. I'm looking for people to speak on (a) why we need this facility, (b) why we don't, or other ways to accomplish the same goal, and (c) proposals for how to modify the ESP header to leak what is desired. >From s003672@cs.tamu.edu Sun Mar 28 15:55:09 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id PAA06662 for ; Sun, 28 Mar 1999 15:55:09 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id PAA21808 for ; Sun, 28 Mar 1999 15:55:08 -0800 (PST) Received: from cs.tamu.edu (IDENT:0@clavin.cs.tamu.edu [128.194.130.106]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id PAA21804 for ; Sun, 28 Mar 1999 15:55:07 -0800 (PST) Received: from hawk.cs.tamu.edu (IDENT:1778@hawk [128.194.135.113]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id RAA00760 for ; Sun, 28 Mar 1999 17:54:15 -0600 (CST) Received: from localhost by hawk.cs.tamu.edu (8.9.3/8.9.3) with SMTP id RAA07644 for ; Sun, 28 Mar 1999 17:54:18 -0600 (CST) X-Authentication-Warning: hawk.cs.tamu.edu: s003672 owned process doing -bs Date: Sun, 28 Mar 1999 17:54:18 -0600 (CST) From: Shishir X-Sender: s003672@hawk To: red-impl@lbl.gov Subject: Holt Winters Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi , I am interested in RED Average queue size calculation using Holt Winters method (implementation is available in ns-2). Can anybody send me a reference to a paper describing this method. Thanx , -Shishir >From Hossam.Afifi@enst-bretagne.fr Mon Mar 29 03:39:00 1999 Received: from melimelo.enst-bretagne.fr (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id DAA07461 for ; Mon, 29 Mar 1999 03:38:46 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA22349 for ; Mon, 29 Mar 1999 13:38:37 +0200 Received: from rennes.enst-bretagne.fr (albemuth.rennes.enst-bretagne.fr [193.52.74.199]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA13124 for ; Mon, 29 Mar 1999 13:38:36 +0200 (MET DST) Sender: Hossam.Afifi@enst-bretagne.fr Message-ID: <36FF663B.D6A3F8A8@rennes.enst-bretagne.fr> Date: Mon, 29 Mar 1999 13:38:35 +0200 From: Hossam Afifi X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4m) MIME-Version: 1.0 To: red-impl@listserv.lbl.gov Subject: two threshold red References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit WRED is now available in the nist simulator with three color marking (heinanen). We noticed some problems in finding the thresholds for the three priorities mechanism: in some situations the probability to drop orange packets can grow larger than the probability to drop red packets due to a set of thresholds that are not well suited... (thresholds should be verified so that lines do not intersect) -- * http://www.rennes.enst-bretagne.fr/~afifi * * Address ENST de Bretagne RSM * * BP 78-35512 Cesson Sevigne CEDEX * -------------------------------------------------------- >From floyd@owl.ee.lbl.gov Mon Mar 29 19:27:32 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id TAA12659 for ; Mon, 29 Mar 1999 19:27:32 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id TAA21727 for ; Mon, 29 Mar 1999 19:27:31 -0800 (PST) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id TAA21723 for ; Mon, 29 Mar 1999 19:27:30 -0800 (PST) Received: (from floyd@localhost) by owl.ee.lbl.gov (8.9.2/8.9.2) id TAA12311; Mon, 29 Mar 1999 19:27:26 -0800 (PST) Message-Id: <199903300327.TAA12311@owl.ee.lbl.gov> To: Shishir cc: red-impl@lbl.gov Subject: Re: Holt Winters Date: Mon, 29 Mar 1999 19:27:26 PST From: Sally Floyd >I am interested in RED Average queue size calculation using Holt Winters >method (implementation is available in ns-2). Can anybody send me a >reference to a paper describing this method. The paper is at "ftp://ftp.ee.lbl.gov/papers/holt.ps.Z". - Sally >From aljtarik@ozias.inrs-telecom.uquebec.ca Wed Jul 14 08:11:34 1999 Received: from ozias.inrs-telecom.uquebec.ca (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA21868 for ; Wed, 14 Jul 1999 08:11:28 -0700 (PDT) Received: from someware.INRS-Telecom.UQuebec.CA (someware [192.26.211.46]) by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with SMTP id LAA19805 for ; Wed, 14 Jul 1999 11:12:21 -0400 (EDT) Received: from someware by someware.INRS-Telecom.UQuebec.CA (SMI-8.6/SMI-SVR4) id LAA07136; Wed, 14 Jul 1999 11:08:16 -0400 Message-Id: <199907141508.LAA07136@someware.INRS-Telecom.UQuebec.CA> Date: Wed, 14 Jul 1999 11:08:16 -0400 (EDT) From: Tarik Alj Reply-To: Tarik Alj Subject: use of RED with token bucket constrained flows To: red-impl@listserv.lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: W4aC1WkQgThQeUVJfCqheA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4m sparc Hi, I am looking for information on the possible use of RED with flows that obey token bucket parameters (such as RSVP's Tspec). I am particularly interested in the possible relations between parameters of RED and token bucket. I am also interested in the use of WRED (Cisco's weighted RED) with the same kind of flows. Thanks in advance for any help, Tarik Alj INRS-Telecommunications 16 place du commerce Verdun (Ile des Soeurs), Qc, H3E 1H6 Canada Tel: 514 761 8611 Fax: 514 761 8619 >From pengxf@sz.huawei.com.cn Thu Jul 15 18:57:04 1999 Received: from mailboy.huawei.com.cn (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id SAA29487 for ; Thu, 15 Jul 1999 18:56:58 -0700 (PDT) Received: from sz.huawei.com.cn ([10.110.92.189]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA12700 for ; Fri, 16 Jul 1999 09:56:28 +0800 Message-ID: <3791343F.D4BD277@sz.huawei.com.cn> Date: Sun, 18 Jul 1999 09:56:16 +0800 From: michael X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: red-impl@listserv.lbl.gov Subject: difference between bursty and fragile Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, What's the difference between bursty traffic and fragile taffic(like telnet)? Thanks in advance for any help. Peng xinfeng >From pengxf@sz.huawei.com.cn Thu Jul 22 03:14:42 1999 Received: from mailboy.huawei.com.cn (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id DAA26807 for ; Thu, 22 Jul 1999 03:14:36 -0700 (PDT) Received: from sz.huawei.com.cn ([10.110.92.189]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA27972 for ; Thu, 22 Jul 1999 18:13:55 +0800 Message-ID: <379991DE.111FB3A3@sz.huawei.com.cn> Date: Sat, 24 Jul 1999 18:13:51 +0800 From: michael X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: red-impl@listserv.lbl.gov Subject: RED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In Cisco's WRED, what is used to calculate the average queue? the entire queue length or the specical precedence packet queue length? In fair queueing implementation, we can use RED based on all buffers,also we can use RED for per-flow with each flow has its own parameters, which one is better? why? Thank you in advance for any help. Peng >From chetansk@wipinfo.soft.net Thu Jul 22 07:40:26 1999 Received: from patriot.wipinfo.soft.net (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA27681 for ; Thu, 22 Jul 1999 07:32:07 -0700 (PDT) Received: from wipro.tcpn.com ([172.31.40.11]) by patriot.wipinfo.soft.net (8.9.2/8.9.2) with ESMTP id TAA17447; Thu, 22 Jul 1999 19:59:54 -0500 (GMT) Received: from mohanam.wipro.tcpn.com (chetansk@mohanam.wipro.tcpn.com [172.31.41.27]) by wipro.tcpn.com (8.9.3/8.9.3) with ESMTP id UAA11007; Thu, 22 Jul 1999 20:01:33 +0530 (IST) Received: from localhost (chetansk@localhost) by mohanam.wipro.tcpn.com (8.8.5/8.8.5) with SMTP id UAA03798; Thu, 22 Jul 1999 20:06:33 +0530 X-Authentication-Warning: mohanam.wipro.tcpn.com: chetansk owned process doing -bs Date: Thu, 22 Jul 1999 20:06:27 +0530 (IST) From: Chetan Kumar To: michael cc: red-impl@listserv.lbl.gov Subject: Re: RED In-Reply-To: <379991DE.111FB3A3@sz.huawei.com.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 24 Jul 1999, michael wrote: *>In Cisco's WRED, what is used to calculate the average queue? the *>entire queue length or the specical *>precedence packet queue length? In fair queueing implementation, we can *>use RED based on all *>buffers,also we can use RED for per-flow with each flow has its own Hi, This is just an information, we are using RED for each flow in CBQ schedular, with parameters being based on allocation for each que. We are yet get any results for analysis. I would like to know if any one on the list have used RED on per flow basis, and any results would be welcome. Thanks -Chetan S *>parameters, which one is better? *>why? *>Thank you in advance for any help. *> *>Peng *> The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw >From owner-red-impl@listserv.lbl.gov Fri Jul 23 20:02:46 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id UAA10098; Fri, 23 Jul 1999 20:02:26 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from mailboy.huawei.com.cn (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA10094 for ; Fri, 23 Jul 1999 20:02:20 -0700 (PDT) Received: from sz.huawei.com.cn ([10.110.92.189]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA27960 for ; Sat, 24 Jul 1999 11:01:35 +0800 Message-ID: <379BCF8B.A69D6BF2@sz.huawei.com.cn> Date: Mon, 26 Jul 1999 11:01:31 +0800 From: michael X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: red-impl@listserv.lbl.gov Subject: RED's minth value Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-red-impl@listserv.lbl.gov Precedence: bulk If we have known the maximum phsical queue size, for example, 1000 packets, are there some role of thumb values of mixth and maxth? Thanks. Peng >From owner-red-impl@listserv.lbl.gov Fri Jul 23 20:34:29 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id UAA10245; Fri, 23 Jul 1999 20:34:26 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from beatrice.rutgers.edu (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with SMTP id UAA10241 for ; Fri, 23 Jul 1999 20:34:23 -0700 (PDT) Received: (from easmith@localhost) by beatrice.rutgers.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA25255; Fri, 23 Jul 1999 23:21:02 -0400 From: "Allen Smith" Message-Id: <9907232321.ZM25253@beatrice.rutgers.edu> Date: Fri, 23 Jul 1999 23:21:02 -0400 In-Reply-To: michael "RED's minth value" (Jul 23, 11:03pm) References: <379BCF8B.A69D6BF2@sz.huawei.com.cn> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: michael , red-impl@listserv.lbl.gov Subject: Re: RED's minth value Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-red-impl@listserv.lbl.gov Precedence: bulk On Jul 23, 11:03pm, michael (possibly) wrote: > If we have known the maximum phsical queue size, for example, 1000 > packets, are there some role of > thumb values of mixth and maxth? While I have as yet no practical experience in the matter, I am suspecting the answer is going to depend more on "what delays going through a gateway are you willing to tolerate" and "how long is your average packet". In other words, set maxth to always discard packets if they'd have a delay longer than you consider tolerable, and minth to 1/3 that. OTOH, it's possible that the maximum physical queue size is already set to an appropriate value... which does have the problem that the modified ("gentle") function for deletions above the threshold, rising to 100% at the maximum physical queue size, no longer makes sense. In my considerations of implementing a very simple version of RED on IPFilter (see http://cheops.anu.edu.au/~avalon/ip-filter.html), I've been doing some thinking on this; I'm trying to come up with a very simple-to-install version that will do as much automatically as possible. I'm therefore looking at figuring out some fixed values. The purpose is also to apply RED to packets that are of lesser priority (and are selected as such by IPFilter rules); therefore, as well as the aforementioned reason for not having maxth equal to the physical queue size, there's also the one of leaving some space in the queue for un-limited packets. In this case, I'm considering the following setup (partially influenced by speed of powers of two divisions/multiplications, and by that the physical queue size is probably a power of two): maxth = 3/4 maximum physical queue size minth = 1/4 maximum physical queue size min_p = automatically adapted, starting at 0.1 w_p = 0.002 deletion function = gentle One question is about the function for figuring out the number of zero-queue-size effective packets (for averaging). This is especially a concern when you've got network interface drivers with their own queues. What I'm thinking of on this is another moving average, with the same w_p; simply track how many packets have been added to and removed from the queue, and figure the time for each packet to be removed from the queue. Any advice on this from those who've tried applying RED? -Allen -- Allen Smith easmith@beatrice.rutgers.edu >From owner-red-impl@listserv.lbl.gov Tue Jul 27 04:24:45 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id EAA20136; Tue, 27 Jul 1999 04:24:22 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from isis.lip6.fr (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id EAA20132 for ; Tue, 27 Jul 1999 04:24:18 -0700 (PDT) Received: from rp.lip6.fr (tyro.lip6.fr [132.227.61.64]) by isis.lip6.fr (8.8.8/jtpda-5.2.9.1+lip6) with ESMTP id NAA19843 for ; Tue, 27 Jul 1999 13:24:16 +0200 (MET DST) Message-ID: <379D9854.7C4F5CA0@rp.lip6.fr> Date: Tue, 27 Jul 1999 13:30:29 +0200 From: Thomas Ziegler X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: red-impl@listserv.lbl.gov Subject: Re: RED's minth value References: <379BCF8B.A69D6BF2@sz.huawei.com.cn> Content-Type: multipart/alternative; boundary="------------1F6364B1A018D565038FE5DA" Sender: owner-red-impl@listserv.lbl.gov Precedence: bulk --------------1F6364B1A018D565038FE5DA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit michael wrote: > If we have known the maximum phsical queue size, for example, 1000 > packets, are there some role of > thumb values of mixth and maxth? > Thanks. > > Peng Our simulations show that (maxth-minth) has to be set as an increasing function of the link capacity and the RTT. With long-living bulk-data TCP flows, (maxth-minth) may be generally set lower than the bandwidth*delay product of a scenario, however, the buffering requirements of RED are still significant. So if you have a buffer of 1000 packets, an OC12 link and long delay you might be in trouble. The problem is that if (maxth-minth) is set too small the queue starts to oscillate causing phases of buffer-overflow (forced drops) followed by phases of link-underutilization when the queue is empty. Note, however, that what I am saying is true for scenarios with long-living bulk data TCP flows. In transient state these oscillations may be not that severe. Generally I find it very difficult to parametrize RED properly in order to make the average queue converge between minth and maxth. For instance, maxp has to be a function of bandwidth, RTT and number of flows (or the agressivity of the flow-aggregate's congestion control mechanisms); If (maxth-minth) or maxp are not set properly the queue won't converge between minth and maxth. Guidelines how to set minth are given in the original RED paper and on Sally Floyd's Web-page. As rough rules of thumb I would recommend to set minth between 10 and 30 packets and maxth to approximately 700 packets if you have a buffer of 1000 packets. best regards Thomas -- Thomas Ziegler -------------------------- Laboratoire d'Informatique de Paris 6 (LIP6), Universite Pierre et Marie Curie tel: (+33) 01.44.27.87.72, fax: (+33) 01.44.27.74.95 ---------------------------------------------------- Techno-Z FH Research, School for Telecommunications, Salzburg, Austria Tel +43.662.454.888.715, fax: +43.662.454.888.174 ----------------------------------------------------------------------------- --------------1F6364B1A018D565038FE5DA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit michael wrote:
If we have known the maximum phsical queue size, for example, 1000
packets, are there some role of
thumb values of mixth and maxth?
Thanks.

Peng

Our simulations show that (maxth-minth) has to be set as an increasing  function of the link capacity and the RTT.
With long-living bulk-data TCP flows, (maxth-minth) may be generally set lower than the bandwidth*delay product of a scenario, however, the buffering requirements of RED are still significant. So if you have a buffer of 1000 packets, an OC12 link and long delay you might be in trouble.

The problem is that  if (maxth-minth) is set  too small the queue starts to oscillate causing phases of buffer-overflow (forced drops)  followed by phases of link-underutilization  when the queue is empty.   Note, however, that what I am saying is true for  scenarios with long-living bulk data TCP flows. In transient state these oscillations may be not that severe.

Generally I find it very difficult to parametrize RED properly in order to make the average queue converge between minth and maxth. For instance, maxp has to be a function of bandwidth, RTT and number of flows (or the agressivity of the flow-aggregate's congestion control mechanisms); If (maxth-minth) or maxp are not set properly the queue won't converge between minth and maxth.

Guidelines how to set minth are given in the original RED paper and on Sally Floyd's Web-page.  As rough rules of thumb I would recommend to set minth between 10 and 30 packets and maxth to approximately 700 packets if you have a buffer of 1000 packets.

best regards

Thomas 

-- 
Thomas Ziegler             
--------------------------
Laboratoire d'Informatique de Paris 6 (LIP6), Universite Pierre et Marie Curie
tel: (+33) 01.44.27.87.72, fax: (+33) 01.44.27.74.95
----------------------------------------------------
Techno-Z FH Research, School for Telecommunications, Salzburg, Austria
Tel +43.662.454.888.715, fax: +43.662.454.888.174                            
-----------------------------------------------------------------------------
  --------------1F6364B1A018D565038FE5DA-- >From owner-red-impl@listserv.lbl.gov Sun Aug 1 19:50:01 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id TAA08311; Sun, 1 Aug 1999 19:48:33 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from mailboy.huawei.com.cn (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id TAA08307 for ; Sun, 1 Aug 1999 19:48:27 -0700 (PDT) Received: from sz.huawei.com.cn ([10.110.92.189]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA6244 for ; Mon, 2 Aug 1999 10:47:30 +0800 Message-ID: <37A506D3.86C8D42D@sz.huawei.com.cn> Date: Mon, 02 Aug 1999 10:47:47 +0800 From: michael X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: red-impl@listserv.lbl.gov Subject: When the queue is empty Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-red-impl@listserv.lbl.gov Precedence: bulk Hi, In RED's implementation, what will happen if we just set the ave_que = 0 when the queue is empty? Thanks. Regards Peng >From owner-red-impl@listserv.lbl.gov Tue Aug 3 04:43:34 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id EAA01913; Tue, 3 Aug 1999 04:41:30 -0700 (PDT) Received: from patriot.wipinfo.soft.net (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id EAA01909 for ; Tue, 3 Aug 1999 04:40:29 -0700 (PDT) Received: from wipro.tcpn.com ([172.31.40.11]) by patriot.wipinfo.soft.net (8.9.2/8.9.2) with ESMTP id RAA09131; Tue, 3 Aug 1999 17:11:13 -0500 (GMT) Received: from mohanam.wipro.tcpn.com (chetansk@mohanam.wipro.tcpn.com [172.31.41.27]) by wipro.tcpn.com (8.9.3/8.9.3) with ESMTP id RAA22244; Tue, 3 Aug 1999 17:12:39 +0530 (IST) Received: from localhost (chetansk@localhost) by mohanam.wipro.tcpn.com (8.8.5/8.8.5) with SMTP id RAA04394; Tue, 3 Aug 1999 17:17:32 +0530 X-Authentication-Warning: mohanam.wipro.tcpn.com: chetansk owned process doing -bs Date: Tue, 3 Aug 1999 17:17:31 +0530 (IST) From: Chetan Kumar To: michael cc: red-impl@listserv.lbl.gov Subject: Re: When the queue is empty In-Reply-To: <37A506D3.86C8D42D@sz.huawei.com.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-red-impl@listserv.lbl.gov Precedence: bulk On Mon, 2 Aug 1999, michael wrote: *>Hi, *> *>In RED's implementation, what will happen if we just set the ave_que = 0 *>when the queue is empty? This should increase the burstness in the network. The philosophy of RED is to decrease the burstiness in the network by calculating ave que as Expnentional Wieghted Moving Average. Now when the que is empty then we need to reduce the que length with the same way such that the que length would decrease exponentionaly(moving) with time constant inversly proportional to link speed.(As if packets are arriving at the gate way at the link speed) -Chetan S *>Thanks. *> *>Regards *>Peng *> The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw >From owner-red-impl@listserv.lbl.gov Tue Aug 10 07:17:59 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id HAA29360; Tue, 10 Aug 1999 07:16:58 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from mail1.its.rpi.edu (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA29356 for ; Tue, 10 Aug 1999 07:16:52 -0700 (PDT) Received: from yet (rts16p15.xyp.rpi.edu [128.113.30.144]) by mail1.its.rpi.edu (8.9.3/8.9.3) with SMTP id KAA101248 for ; Tue, 10 Aug 1999 10:16:46 -0400 Message-ID: <000f01bee33c$2f3814e0$02000003@yet> From: "Tao Ye" To: Subject: Any RED implementation for Linux? Date: Tue, 10 Aug 1999 10:25:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-red-impl@listserv.lbl.gov Precedence: bulk Hi, Now I need to do some work with RED under Linux. Is there any RED implementation for Linux publicly availabe? I can only find the implemenation for FreeBSD and Solaris from the RED homepage. Thanks a lot! Tao >From owner-red-impl@listserv.lbl.gov Tue Aug 10 14:44:20 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id OAA04909; Tue, 10 Aug 1999 14:42:34 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from elk.aciri.org (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id OAA04873 for ; Tue, 10 Aug 1999 14:42:32 -0700 (PDT) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id OAA38709; Tue, 10 Aug 1999 14:42:22 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <199908102142.OAA38709@elk.aciri.org> To: "Tao Ye" cc: red-impl@listserv.lbl.gov From: Sally Floyd Subject: Re: Any RED implementation for Linux? Date: Tue, 10 Aug 1999 14:42:22 -0700 Sender: owner-red-impl@listserv.lbl.gov Precedence: bulk Tao - >Is there any RED >implementation for Linux publicly availabe? I just added the following citation to the RED web page. Thanks to Jamal for the citation... The RED implementation in Linux was written by Alexey Kuznetsov. RED is supported in the official stable 2.2.* kernel. (RED is also supported in Linux kernels 2.1.129 and above. 2.1.* is a development kernel, and the RED implementation from releases prior to 2.1.129 should not be used.) Jamal Hadi Salim has written a multi-level RED variant, GRED, for Linux. GRED can run up to 16 virtual queues on a single physical queue. This is described further in a document on "Differentiated Services on Linux". GRED can operate in "RIO mode", with coupled average queue estimates from the virtual queues, or in "standard mode" where each virtual queue has its own independent average queue estimate. - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- >From owner-red-impl@listserv.lbl.gov Thu Aug 12 01:28:16 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id BAA12357; Thu, 12 Aug 1999 01:27:24 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from uumail-relay-blr.ernet.in (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id BAA12353 for ; Thu, 12 Aug 1999 01:27:10 -0700 (PDT) Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by uumail-relay-blr.ernet.in (8.9.0/8.9.0) with SMTP id OAA29453 for ; Thu, 12 Aug 1999 14:00:34 +0530 Received: from protocol.ece.iisc.ernet.in by ece.iisc.ernet.in (4.1/SMI-4.1) id AA01912; Thu, 12 Aug 99 13:56:50+0530 Received: from localhost (nadeem@localhost) by protocol.ece.iisc.ernet.in (8.8.7/8.8.7) with SMTP id NAA23986 for ; Thu, 12 Aug 1999 13:25:02 +0530 Date: Thu, 12 Aug 1999 13:25:02 +0530 (IST) From: Nadeem Akhtar To: red-impl@listserv.lbl.gov Subject: Performance Analysis of RED. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-red-impl@listserv.lbl.gov Precedence: bulk Hi, I'm searching for literature on Performance Analysis of RED, particularly for TCP kind of traffic. Can somebody help me with some specific info in this regard. I've already visited the webpage of Sally Floyd. Bye. **************************************************************************** Nadeem Akhtar Snailm@il: M.E(Telecom), R-15, Students Hostel, Deptt.of ECE, IISc, Bangalore. (PIN 560012) Indian Institute of Science INDIA. Phone : 080-3092539 GET CONNECTED,STAY CONNECTED!! >From owner-red-impl@listserv.lbl.gov Sat Aug 14 12:52:52 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA21747; Sat, 14 Aug 1999 12:52:22 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from elk.aciri.org (elk.aciri.org [192.150.187.21]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA21743 for ; Sat, 14 Aug 1999 12:52:20 -0700 (PDT) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id MAA94783; Sat, 14 Aug 1999 12:52:02 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <199908141952.MAA94783@elk.aciri.org> To: michael cc: red-impl@listserv.lbl.gov From: Sally Floyd Subject: Re: When the queue is empty Date: Sat, 14 Aug 1999 12:52:01 -0700 Sender: owner-red-impl@lbl.gov Precedence: bulk >In RED's implementation, what will happen if we just set the ave_que = 0 >when the queue is empty? Consider a scenario where a burst of N packets arrives back to back to an empty queue, so that a large transient queue is created and slowly drains, and that soon after the queue goes idle and the process is repeated (and repeated and repeated...). So the instantaneous queue size has large oscillations, always returning briefly to empty. Consider a value of N such that, if you set ave_que to zero when the queue goes idle, the average queue size never exceeds minthresh, and no packets are ever dropped. If you *do* set ave_que to zero when the queue is empty, then this highly oscillating queue will never be detected as congestion. If you *don't* set ave_que to zero when the queue is empty, then the "true" average queue size will be calculated, and RED will respond appropriately. So it involves the tradeoff between high throughput and low average queueing delay. If you care about controlling the average queueing delay, then the only choice is *not* to set ave_que to zero when the queue is empty. If you don't care about the average queueing delay, but *only* care about maximizing throughput, then you might make a different choice. - Sally >From owner-red-impl@listserv.lbl.gov Mon Aug 16 08:37:42 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA24943; Mon, 16 Aug 1999 08:37:08 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from uumail-relay-blr.ernet.in (uumail-relay-blr.ernet.in [202.141.1.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA24939 for ; Mon, 16 Aug 1999 08:37:03 -0700 (PDT) Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by uumail-relay-blr.ernet.in (8.9.0/8.9.0) with SMTP id VAA13504 for ; Mon, 16 Aug 1999 21:10:43 +0530 Received: from protocol.ece.iisc.ernet.in by ece.iisc.ernet.in (4.1/SMI-4.1) id AA24557; Mon, 16 Aug 99 21:06:59+0530 Received: from localhost (nadeem@localhost) by protocol.ece.iisc.ernet.in (8.8.7/8.8.7) with SMTP id UAA13929 for ; Mon, 16 Aug 1999 20:36:18 +0530 Date: Mon, 16 Aug 1999 20:36:18 +0530 (IST) From: Nadeem Akhtar To: red-impl@listserv.lbl.gov Subject: Queue Length Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-red-impl@lbl.gov Precedence: bulk Hi, If we calculate the buffer occupancy in no of bits rather than as no of packets, what modifications have to be made in the RED algo. ? ? **************************************************************************** Nadeem Akhtar Snailm@il: M.E(Telecom), R-15, Students Hostel, Deptt.of ECE, IISc, Bangalore. (PIN 560012) Indian Institute of Science INDIA. Phone : 080-3092539 GET CONNECTED,STAY CONNECTED!! >From owner-red-impl@listserv.lbl.gov Wed Nov 24 07:04:04 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA25194; Wed, 24 Nov 1999 07:03:22 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA25190 for ; Wed, 24 Nov 1999 07:03:19 -0800 (PST) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id KAA05972; Wed, 24 Nov 1999 10:03:19 -0500 (EST) Message-Id: <199911241503.KAA05972@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: red-impl@listserv.lbl.gov cc: vishnu@torrentnet.com Subject: Control law recalculation interval Date: Wed, 24 Nov 1999 10:03:18 -0500 From: Steve Blake Sender: owner-red-impl@lbl.gov Precedence: bulk Greetings, A question came up while working on an implementation of RED. Is it ever necessary to recompute the nominal packet drop probability within an interval less than the minimum RTT of traffic serviced by the link? By 'nominal' I am excluding packet-by-packet changes to alter the inter-drop distribution. The argument supporting the assertion that it is not necessary to recompute more frequently than min RTT is that the trajectory of the average queue over a min RTT interval won't be affected by changes in the nominal drop probability within the interval since the traffic is already in flight and the sources cannot react more quickly than min RTT. I'm curious if anyone has given thought to this. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)468-8466 x232 >From owner-red-impl@listserv.lbl.gov Wed Nov 24 12:18:26 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA25963; Wed, 24 Nov 1999 12:18:12 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from elk.aciri.org (elk.aciri.org [192.150.187.21]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA25959 for ; Wed, 24 Nov 1999 12:18:11 -0800 (PST) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id MAA04509; Wed, 24 Nov 1999 12:18:03 -0800 (PST) (envelope-from floyd@elk.aciri.org) Message-Id: <199911242018.MAA04509@elk.aciri.org> To: Steve Blake cc: red-impl@listserv.lbl.gov, vishnu@torrentnet.com From: Sally Floyd Subject: Re: Control law recalculation interval Date: Wed, 24 Nov 1999 12:18:03 -0800 Sender: owner-red-impl@lbl.gov Precedence: bulk >A question came up while working on an implementation of RED. Is it ever >necessary to recompute the nominal packet drop probability within an interval >less than the minimum RTT of traffic serviced by the link? By 'nominal' I >am excluding packet-by-packet changes to alter the inter-drop distribution. > >The argument supporting the assertion that it is not necessary to recompute >more frequently than min RTT is that the trajectory of the average queue >over a min RTT interval won't be affected by changes in the nominal drop >probability within the interval since the traffic is already in flight and >the sources cannot react more quickly than min RTT. My guess would be that you could get *acceptable* performance from RED with only re-computing the average queue size and the packet drop probability once per min RTT. However, I think you could see somewhat better responsiveness from re-computing more frequently than that, particularly in the case where a large burst of packets arrived over a period of a min RTT to the queue, resulting in a large (possibly transient, but possibly not) queue. One example would be for a TCP slow-starting into an empty queue. The sooner the router detects the queue building up, and translates this to an increased average queue size and increased packet dropping probability, the sooner the end node can stop its slow-start. But I actually don't have a suggestion for how to quantify the benefit of re-computing more frequently, and explore more carefully the performance tradeoffs... - Sally >From owner-red-impl@listserv.lbl.gov Thu May 4 09:39:55 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA29567; Thu, 4 May 2000 09:38:28 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA29563 for ; Thu, 4 May 2000 09:38:26 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26105 for ; Thu, 4 May 2000 09:38:25 -0700 (PDT) Received: from craius.cportcorp.com ([207.180.133.130]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26089 for ; Thu, 4 May 2000 09:38:24 -0700 (PDT) Received: by craius.cportcorp.com with Internet Mail Service (5.5.2448.0) id <262XQWSK>; Thu, 4 May 2000 12:33:37 -0400 Message-ID: From: Jeff Wise To: "'red-impl@lbl.gov'" Subject: Date: Thu, 4 May 2000 12:33:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-red-impl@lbl.gov Precedence: bulk I am interested in doing an implementation of RED that includes dynamically shared buffering for the short-term traffic bursts. My queues are implemented in hardware as linked lists. In this scheme, when a queue's depth is above a certain threshold, the availability of additional buffers for the queue depends on the amount of buffers in use by the other queues in the "buffer pool." Since a certain number of buffers are shared among a set of queues, the buffers can be used in the traffic "hot-spots." This scheme gives the system the appearance of having many more buffers than it actually has as compared to schemes where the buffers for each queue are dedicated to just that queue. Section 7b of RFC-2597 (pg 7) discusses the allocation of "excess resources". Has further thinking been done on this in the IETF, is anything published, or can anyone share their thinking or experiences? Thanks, Jeffrey Wise Cport Corp. N. Andover, MA (978) 773-2362 jwise@cportcorp.com >From owner-red-impl@listserv.lbl.gov Thu May 4 14:37:05 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA01383; Thu, 4 May 2000 14:36:43 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA01379 for ; Thu, 4 May 2000 14:36:41 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA10137 for ; Thu, 4 May 2000 14:36:40 -0700 (PDT) Received: from craius.cportcorp.com ([207.180.133.130]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA10126 for ; Thu, 4 May 2000 14:36:39 -0700 (PDT) Received: by craius.cportcorp.com with Internet Mail Service (5.5.2448.0) id <262XQXF7>; Thu, 4 May 2000 17:31:53 -0400 Message-ID: From: Jeff Wise To: "'red-impl@lbl.gov'" Subject: When to update the average queue length Date: Thu, 4 May 2000 17:31:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-red-impl@lbl.gov Precedence: bulk The 1993 paper first describing RED has the average queue length update calculation occuring with each packet arrival (figure 2 on pg 8). Another approach would be to do the update calculations as a background task at regular time intervals, independent of packet arrivals or departures. Independent of implementation issues, is there any functional reason to use one update stategy over the other? Thanks, Jeffrey Wise C-Port Corp. N. Andover, MA (978) 773-2362 jwise@cportcorp.com >From owner-red-impl@listserv.lbl.gov Thu May 4 14:49:21 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA01414; Thu, 4 May 2000 14:49:19 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA01410 for ; Thu, 4 May 2000 14:49:17 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA15760 for ; Thu, 4 May 2000 14:49:16 -0700 (PDT) Received: from lobster.baynetworks.com (ns3.BayNetworks.COM [192.32.253.3]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA15751 for ; Thu, 4 May 2000 14:49:15 -0700 (PDT) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id RAA09869; Thu, 4 May 2000 17:52:34 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id RAA17493; Thu, 4 May 2000 17:53:03 -0400 (EDT) Received: from katahdin.engeast (katahdin [192.32.88.77]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA10412; Thu, 4 May 2000 17:48:13 -0400 for Received: by katahdin.engeast (SMI-8.6/SMI-SVR4) id RAA00927; Thu, 4 May 2000 17:48:13 -0400 From: anoop@BayNetworks.COM (Anoop Ghanwani) Message-Id: <200005042148.RAA00927@katahdin.engeast> Subject: Re: When to update the average queue length In-Reply-To: from Jeff Wise at "May 4, 2000 05:31:46 pm" To: Jeff Wise Date: Thu, 4 May 2000 17:48:13 -0400 (EDT) CC: "'red-impl@lbl.gov'" X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-red-impl@lbl.gov Precedence: bulk If one did it using regular time intervals, then one might have to go hunting for a good value of the interval, a number which actually depends on the traffic arrival rate. For e.g. a measurement interval on the order of milliseconds may be acceptable on low speed links, but may be too large on multi-gigabit links. Therefore, I think it's better to do the update calculation with each packet arrival (or with every n packet arrivals) because it would make the measurements independent of the arrival rate. -Anoop [Charset iso-8859-1 unsupported, filtering to ASCII...] > The 1993 paper first describing RED has the average queue length > update calculation occuring with each packet arrival (figure 2 on pg 8). > Another approach would be to do the update calculations as a > background task at regular time intervals, independent of packet arrivals > or departures. > > Independent of implementation issues, is there any functional reason > to use one update stategy over the other? >From owner-red-impl@listserv.lbl.gov Thu May 4 15:28:14 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA01492; Thu, 4 May 2000 15:28:12 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA01488 for ; Thu, 4 May 2000 15:28:10 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA29634 for ; Thu, 4 May 2000 15:28:09 -0700 (PDT) Received: from olympus.eecs.umich.edu (olympus.eecs.umich.edu [141.213.8.56]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA29626 for ; Thu, 4 May 2000 15:28:08 -0700 (PDT) Received: from localhost (wuchang@localhost) by olympus.eecs.umich.edu (8.9.3/8.9.1) with ESMTP id SAA13804; Thu, 4 May 2000 18:27:56 -0400 (EDT) Date: Thu, 4 May 2000 18:27:56 -0400 (EDT) From: Wu-chang Feng To: Jeff Wise cc: "'red-impl@lbl.gov'" Subject: Re: When to update the average queue length In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-red-impl@lbl.gov Precedence: bulk I did some w_q twiddling a while ago. Look at http://www.eecs.umich.edu/~wuchang/blue It shows how the performance of the algorithm changes based on it. Wu On Thu, 4 May 2000, Jeff Wise wrote: > The 1993 paper first describing RED has the average queue length > update calculation occuring with each packet arrival (figure 2 on pg 8). > Another approach would be to do the update calculations as a > background task at regular time intervals, independent of packet arrivals > or departures. > > Independent of implementation issues, is there any functional reason > to use one update stategy over the other? > > > Thanks, > > Jeffrey Wise > C-Port Corp. > N. Andover, MA > (978) 773-2362 > jwise@cportcorp.com > > > >From owner-red-impl@listserv.lbl.gov Thu May 4 15:40:20 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA01614; Thu, 4 May 2000 15:38:39 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA01610 for ; Thu, 4 May 2000 15:38:37 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA02688 for ; Thu, 4 May 2000 15:38:37 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA02685 for ; Thu, 4 May 2000 15:38:31 -0700 (PDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Thu, 4 May 2000 18:24:22 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KHL0JSCJ; Thu, 4 May 2000 18:24:21 -0400 Received: from nortelnetworks.com (dhcp223-154.engeast.baynetworks.com [192.32.223.154]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JS0RRDHV; Thu, 4 May 2000 18:24:19 -0400 Message-ID: <3911F87D.B2F1368D@nortelnetworks.com> Date: Thu, 04 May 2000 18:23:57 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Victor Firoiu" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en]C-{C-UDP; SSBARNEY} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Wise CC: anoop@BayNetworks.COM, "'red-impl@lbl.gov'" Subject: Re: When to update the average queue length References: <200005042148.RAA00927@katahdin.engeast> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-red-impl@lbl.gov Precedence: bulk Jeff, it's actually a bit more complicated, in that the sampling rate should be tied with the queue weight w. This is explained in our recent paper http://www.ieee-infocom.org/2000/papers/405.pdf Take a look and if you have more questions, let me know. Those results are confirmed by a paper to be in Sigcomm 2000 Vishal Misra et al "Fluid-based analysis of a network of AQM routers supporting TCP flows with an application to RED" you can find it in a few days at http://www.acm.org/sigs/sigcomm/sigcomm2000/ >From owner-red-impl@listserv.lbl.gov Thu May 4 16:22:21 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id QAA02296; Thu, 4 May 2000 16:21:58 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA02292 for ; Thu, 4 May 2000 16:21:56 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA15400 for ; Thu, 4 May 2000 16:21:55 -0700 (PDT) Received: from elk.aciri.org (elk.aciri.org [192.150.187.21]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA15380 for ; Thu, 4 May 2000 16:21:54 -0700 (PDT) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.3) with ESMTP id QAA37157; Thu, 4 May 2000 16:21:52 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <200005042321.QAA37157@elk.aciri.org> To: Jeff Wise cc: "'red-impl@lbl.gov'" From: Sally Floyd Subject: Re: When to update the average queue length Date: Thu, 04 May 2000 16:21:52 -0700 Sender: owner-red-impl@lbl.gov Precedence: bulk >The 1993 paper first describing RED has the average queue length >update calculation occuring with each packet arrival (figure 2 on pg 8). >Another approach would be to do the update calculations as a >background task at regular time intervals, independent of packet arrivals >or departures. > >Independent of implementation issues, is there any functional reason >to use one update stategy over the other? I don't know of any pressing reason not to compute the average queue size as a background task at regular time intervals, as long as it is done sufficiently frequently. Of course, the less frequently you update the average queue size, the more sluggish will be your response to a sudden increase in congestion. An implementation-related *disadvantage* to updating the average queue size for each packet arrival is that some extra care has to be taken in considering the periods when the queue has been idle, as described in the RED paper. And of course the average computed at packet arrivals is not precisely the same as the average computed by some other method. - Sally >From owner-red-impl@listserv.lbl.gov Fri May 5 08:49:30 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA05718; Fri, 5 May 2000 08:49:06 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05706 for ; Fri, 5 May 2000 08:49:04 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05981 for ; Fri, 5 May 2000 08:49:03 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05972 for ; Fri, 5 May 2000 08:49:02 -0700 (PDT) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Fri, 5 May 2000 10:29:05 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KDP2QRN5; Fri, 5 May 2000 08:28:57 -0700 Received: from nortelnetworks.com (dhcp223-154.engeast.baynetworks.com [192.32.223.154]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JS0RR1MR; Fri, 5 May 2000 11:28:55 -0400 Message-ID: <3912E8A4.8B67A2BF@nortelnetworks.com> Date: Fri, 05 May 2000 11:28:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Victor Firoiu" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en]C-{C-UDP; SSBARNEY} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "'red-impl@lbl.gov'" CC: Sally Floyd , Jeff Wise Subject: Re: When to update the average queue length References: <200005042321.QAA37157@elk.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-red-impl@lbl.gov Precedence: bulk Sally Floyd wrote: > > I don't know of any pressing reason not to compute the average > queue size as a background task at regular time intervals, as long > as it is done sufficiently frequently. Of course, the less frequently > you update the average queue size, the more sluggish will be your > response to a sudden increase in congestion. > I agree, in the context of w being a constant with respect to \delta, the time between two consecutive queue samples. In general, if you change \delta but also change w such that \delta/w is a constant, then the response is approximately the same. In my Infocom2000 paper I use I=\delta/w as the "memory" of the queue average, i.e., the time interval from which samples are significant in the current average. We recommend I to be order of a TCP window period, typically, 10-30*RTT. Of course, care should be taken to have enough samples in the "memory", such as at least 30..100, i.e., w at most 0.03..0.01. It follows that \delta should be smaller than about RTT/3. A typical RTT is 100-200ms. The above are simplifications of a bit more complicated calculations that can be experimented with at http://www.innovationslab.com/redconfig In the new Sigcomm2000 paper, K=1/I is the threshold frequency of the low-pass filter constituted by the queue average. That means that the queue average responds only to variations of queue of frequencies lower than K. -- Victor >From owner-red-impl@listserv.lbl.gov Fri May 5 14:59:01 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA06969; Fri, 5 May 2000 14:57:03 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-red-impl@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA06965 for ; Fri, 5 May 2000 14:57:01 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA29434 for ; Fri, 5 May 2000 14:57:01 -0700 (PDT) Received: from craius.cportcorp.com ([207.180.133.130]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA29427 for ; Fri, 5 May 2000 14:57:00 -0700 (PDT) Received: by craius.cportcorp.com with Internet Mail Service (5.5.2448.0) id <262XQY9Y>; Fri, 5 May 2000 17:52:13 -0400 Message-ID: From: Jeff Wise To: "'red-impl@lbl.gov'" Cc: Jeff Wise Subject: Dynamically shared buffering resources in RED Date: Fri, 5 May 2000 17:52:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-red-impl@lbl.gov Precedence: bulk > I am interested in doing an implementation of RED that includes > dynamically > shared buffering for the short-term traffic bursts. My queues are > implemented > in hardware as linked lists. > > In this scheme, when a queue's depth is above a certain threshold, the > availability > of additional buffers for the queue depends on the amount of buffers in > use by the > other queues in the "buffer pool." Since a certain number of buffers are > shared > among a set of queues, the buffers can be used in the traffic "hot-spots." > This > scheme gives the system the appearance of having many more buffers than > it actually has as compared to schemes where the buffers for each queue > are > dedicated to just that queue. > > Section 7b of RFC-2597 (pg 7) discusses the allocation of "excess > resources". > Has further thinking been done on this in the IETF, is anything published, > or can > anyone share their thinking or experiences? > > > Thanks, > > Jeffrey Wise > Cport Corp. > N. Andover, MA > (978) 773-2362 > jwise@cportcorp.com > > P.S. This is a repeat submission of a message originally sent without a subject.