Date: Sat, 19 Feb 2000 16:30:31 PST To: floyd@aciri.org From: Majordomo@lbl.gov Subject: Majordomo file: list 'red-impl' file 'archive' -- 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 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/ -------------------------------- 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 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 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 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 knowledgeon 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 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 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 alinear 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 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 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 possiblespeed 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 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 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 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 (65 1.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 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 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. 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 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 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 Ja n 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 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 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 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 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 us e 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 > > > > 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... 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 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 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 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: 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. 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 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 * -------------------------------------------------------- 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 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 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 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 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 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: "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 2 3, 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 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="------------1F6364B1A018D565038F E5DA" 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-livi ng 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     
             &
nbsp;         
-----------------------------------------------------------------------------
 

--------------1F6364B1A018D565038FE5DA--


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


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



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


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/
--------------------------------


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!!


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 everdropped.

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

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!!


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



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