RFC 2309

RFC 2309: Recommendations on Queue Management and Congestion Avoidance in the Internet 🎀

okay bestie, this is the RFC that basically says "hey, routers need to step up" 💅

• Authors: B. Braden (USC/ISI), D. Clark (MIT LCS), J. Crowcroft (UCL), B. Davie (Cisco Systems), S. Deering (Cisco Systems), D. Estrin (USC), S. Floyd (LBNL), V. Jacobson (LBNL), G. Minshall (Fiberlane), C. Partridge (BBN), L. Peterson (University of Arizona), K. Ramakrishnan (ATT Labs Research), S. Shenker (Xerox PARC), J. Wroclawski (MIT LCS), L. Zhang (UCLA) 🫶
• Category: Informational 📚
• Date: April 1998 🌸
• Obsoletes / updates: the header doesn't list any RFCs that this one obsoletes or updates ✨

---

Status of Memo

so this memo is just giving info to the Internet community 🧚 It does not specify an Internet standard of any kind, so it's not a rule book, it's a vibe check with receipts. Distribution of this memo is unlimited 🌈

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

Abstract

ngl this abstract is giving two big recs 💖 The first is to the Internet community about measures to improve and preserve Internet performance. The memo makes a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, so today's Internet actually runs better 🔥 It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms that protect the Internet from flows that aren't sufficiently responsive to congestion notification. Main character energy for routers 👑

1. INTRODUCTION ✨

okay so the Internet protocol architecture is built on a connectionless end-to-end packet service using the IP protocol 🦋 Connectionless design, flexibility, and robustness have been amply demonstrated, and they are seriously iconic 😭 But these advantages aren't free. Careful design is required to provide good service under heavy load, because lack of attention to the dynamics of packet forwarding can cause severe service degradation, or "Internet meltdown" 💀 This was first observed during the early growth phase of the Internet of the mid 1980s [Nagle84], and it's technically called "congestion collapse."

the original fix for Internet meltdown came from Van Jacobson 🧚‍♀️ Starting in 1986, Jacobson developed the congestion avoidance mechanisms that are now required in TCP implementations [Jacobson88, HostReq89]. These mechanisms operate in the hosts to make TCP connections "back off" during congestion. We say that TCP flows are "responsive" to congestion signals (i.e., dropped packets) from the network. Honestly, it's these TCP congestion avoidance algorithms that mainly keep today's Internet from congestion collapse 🙌

but that's not the end of the story 👀 Lots of research has been done on Internet dynamics since 1988, and the Internet has grown a lot. It's become clear that the TCP congestion avoidance mechanisms [RFC2001], while necessary and powerful, are not sufficient to provide good service in all circumstances. Basically, there's a limit to how much control can be accomplished from the edges of the network. So some mechanisms are needed in the routers to complement the endpoint congestion avoidance mechanisms 🍓

It's useful to tell apart two classes of router algorithms related to congestion control: "queue management" versus "scheduling" algorithms 🎀 To a rough approximation, queue management algorithms manage the length of packet queues by dropping packets when necessary or appropriate. Scheduling algorithms determine which packet to send next, and they're used mainly to manage the allocation of bandwidth among flows. These two router mechanisms are closely related, but they address rather different performance issues, so they're not the same girl 💅

this memo highlights two router performance issues 🌟 The first is the need for an advanced form of router queue management that we call "active queue management." Section 2 summarizes the benefits that active queue management can bring. Section 3 describes a recommended active queue management mechanism called Random Early Detection, or "RED." We expect the RED algorithm can be used with a wide variety of scheduling algorithms, can be implemented relatively efficiently, and will provide significant Internet performance improvement 🔥

the second issue, discussed in Section 4 of this memo, is the potential for future congestion collapse of the Internet due to flows that are unresponsive, or not sufficiently responsive, to congestion indications 😭 Unfortunately, there is no consensus solution to controlling congestion caused by such aggressive flows. Significant research and engineering will be required before any solution is available. It is imperative that this work be energetically pursued, to ensure the future stability of the Internet 🙏

Section 5 concludes the memo with a set of recommendations to the IETF concerning these topics 🧚

the discussion in this memo applies to "best-effort" traffic 🦋 The Internet integrated services architecture, which provides a mechanism for protecting individual flows from congestion, introduces its own queue management and scheduling algorithms [Shenker96, Wroclawski96]. Similarly, the discussion of queue management and congestion control requirements for differential services is a separate issue. Still, we don't expect the deployment of integrated services and differential services to significantly diminish the importance of the best-effort traffic issues discussed in this memo. Best-effort is NOT giving forgotten 💖

this memo came out of past discussions of end-to-end performance, Internet congestion, and RED in the End-to-End Research Group of the Internet Research Task Force (IRTF) 🌈✨

2. THE NEED FOR ACTIVE QUEUE MANAGEMENT ✨

okay so the old-school way routers handle queue lengths is called tail drop 💅. you pick a max length (in packets) for each queue, keep accepting packets until you hit it, then reject (drop) every new packet until the queue shrinks because something got transmitted. it's called "tail drop" bc the packet that arrived most recently (aka the one on the tail of the queue) is the one that gets dropped when the queue is full. honestly this has served the Internet well for years 🌸 but it has two important drawbacks, bestie 😭

1. Lock-Out

ngl this one is kind of unfair 🙈. in some situations tail drop lets a single connection, or a few flows, hog all the queue space so other connections literally can't get a spot in line. this "lock-out" phenomenon is often the result of synchronization or other timing effects.

2. Full Queues

tail drop lets queues stay full (or almost full) for long periods of time, since it only signals congestion (via a packet drop) once the queue has become full 💀. it's important to reduce the steady-state queue size, and this is perhaps queue management's most important goal 👑

the naive assumption might be that there's a simple tradeoff between delay and throughput, and that keeping queues in a "non-full" state basically means low end-to-end delay matters more than high throughput. but that ignores the critical role that packet bursts play in Internet performance 🎀. even though TCP constrains a flow's window size, packets often arrive at routers in bursts [Leland94]. if the queue is full or almost full, an arriving burst causes multiple packets to be dropped. this can cause a global synchronization of flows throttling back, followed by a sustained period of lowered link utilization, which reduces overall throughput 😩.

the point of buffering in the network is to absorb data bursts and transmit them during the (hopefully) ensuing bursts of silence ✨. this is essential to permit the transmission of bursty data. it should be clear why we'd want normally-small queues in routers: we want queue capacity to absorb the bursts. the counter-intuitive result is that maintaining normally-small queues can give you higher throughput as well as lower end-to-end delay 🤯. in short, queue limits should not reflect the steady state queues we want maintained in the network. instead, they should reflect the size of bursts we need to absorb 🫶.

Besides tail drop, two alternative queue disciplines that can be applied when the queue becomes full are "random drop on full" or "drop front on full" 🦋. under "random drop on full", a router drops a randomly selected packet from the queue (which can be an expensive operation, since it naively requires an O(N) walk through the packet queue) when the queue is full and a new packet arrives. under the "drop front on full" discipline [Lakshman96], the router drops the packet at the front of the queue when the queue is full and a new packet arrives. both of these solve the lock-out problem, but neither solves the full-queues problem described above 💅.

We know in general how to solve the full-queues problem for "responsive" flows, i.e., those flows that throttle back in response to congestion notification 🌈. in the current Internet, dropped packets serve as a critical mechanism of congestion notification to end nodes. the solution to the full-queues problem is for routers to drop packets before a queue becomes full, so end nodes can respond to congestion before buffers overflow. we call this proactive approach "active queue management" 🧚. by dropping packets before buffers overflow, active queue management lets routers control when and how many packets to drop. the next section introduces RED, an active queue management mechanism that solves both problems listed above (given responsive flows) 👑.

In summary, an active queue management mechanism can provide the following advantages for responsive flows ⭐.

1. Reduce number of packets dropped in routers

packet bursts are an unavoidable aspect of packet networks [Willinger95] 🌸. if all the queue space in a router is already committed to "steady state" traffic, or if the buffer space is inadequate, the router has no ability to buffer bursts. by keeping the average queue size small, active queue management gives more capacity to absorb naturally-occurring bursts without dropping packets.

and without active queue management, more packets get dropped when a queue does overflow, which is undesirable for a few reasons 😭. first, with a shared queue and the tail drop discipline, an unnecessary global synchronization of flows cutting back can lower average link utilization, and hence lower network throughput. second, TCP recovers with more difficulty from a burst of packet drops than from a single packet drop. third, unnecessary packet drops represent a possible waste of bandwidth on the way to the drop point.

we note that while RED can manage queue lengths and reduce end-to-end latency even in the absence of end-to-end congestion control, RED will only be able to reduce packet dropping in an environment that continues to be dominated by end-to-end congestion control 💖.

2. Provide lower-delay interactive service

by keeping the average queue size small, queue management reduces the delays seen by flows 🍓. this is especially important for interactive applications like short Web transfers, Telnet traffic, or interactive audio-video sessions, whose subjective (and objective) performance is better when end-to-end delay is low ✨.

3. Avoid lock-out behavior

active queue management can prevent lock-out behavior by making sure there will almost always be a buffer available for an incoming packet 🎀. for the same reason, it can also keep a router from being biased against low bandwidth but highly bursty flows.

lock-out is clearly undesirable because it's a gross unfairness among groups of flows 😤. however, we stop short of calling this benefit "increased fairness", because general fairness among flows requires per-flow state, which queue management does not provide 🙅‍♀️. for example, in a router using queue management but only FIFO scheduling, two TCP flows may receive very different bandwidths simply because they have different round-trip times [Floyd91]. and a flow that does not use congestion control may receive more bandwidth than a flow that does. per-flow state to achieve general fairness might be maintained by a per-flow scheduling algorithm such as Fair Queueing (FQ) [Demers90], or a class-based scheduling algorithm such as CBQ [Floyd95], for example 🦋.

on the other hand, active queue management is needed even for routers that use per-flow scheduling algorithms like FQ or class-based scheduling algorithms like CBQ 💅. this is because per-flow scheduling algorithms by themselves do nothing to control the overall queue size or the size of individual queues. active queue management is needed to control the overall average queue sizes, so arriving bursts can be accommodated without dropping packets. in addition, active queue management should be used to control the queue size for each individual flow or class, so they don't experience unnecessarily high delays. therefore, active queue management should be applied across the classes or flows as well as within each class or flow 🌈.

in short, scheduling algorithms and queue management should be seen as complementary, not as replacements for each other 🫶. in particular, there have been implementations of queue management added to FQ, and work is in progress to add RED queue management to CBQ 🔥.

3. THE QUEUE MANAGEMENT ALGORITHM "RED" ✨

okay bestie, this is the good part 💖 Random Early Detection, aka RED, is an active queue management algorithm for routers that's gonna give us the Internet performance glow-up we just talked about [RED93] 🦋. Traditional queue management just drops packets once the buffer is totally full 😬. RED is way smarter. It drops arriving packets probabilistically, so sometimes a packet gets dropped even before the queue is full. The chance of a drop goes up as the estimated average queue size grows.

Here's the detail that makes it iconic: RED responds to a time-averaged queue length, not an instantaneous one 🧠. So if the queue has been mostly empty in the "recent past," RED won't really drop packets (unless the queue overflows, of course!) 🙈. But if the queue has been relatively full lately, which signals persistent congestion, newly arriving packets are more likely to get dropped. It's giving early warning, not panic.

The RED algorithm itself has two main parts: estimating the average queue size, and deciding whether or not to drop an incoming packet 🎀.

(a) Estimation of Average Queue Size

RED estimates the average queue size either in the forwarding path, using a simple exponentially weighted moving average (like the one in Appendix A of [Jacobson88]), or in the background (aka not in the forwarding path) using a similar mechanism 🧚.

Note: The queue size can be measured either in units of packets or of bytes. This issue is discussed briefly in [RED93] in the "Future Work" section.

Note: When the average queue size is computed in the forwarding path, there's a special case when a packet arrives and the queue is empty. In that case, the computation has to account for how much time has passed since the queue went empty. This is discussed further in [RED93] 💅.

(b) Packet Drop Decision

In the second part of the algorithm, RED decides whether or not to drop an incoming packet 👑. This is RED's special dropping algorithm, and it's what delivers the performance improvement for responsive flows. Two RED parameters, minth (minimum threshold) and maxth (maximum threshold), are the stars of this decision. Minth is the average queue size below which no packets get dropped, and maxth is the average queue size above which all packets get dropped 😭. As the average queue size moves from minth to maxth, packets get dropped with a probability that rises linearly from 0 to maxp 📈.

Note: A simplistic way to implement this would be to calculate a new random number at each packet arrival, then compare that number with the above probability, which goes from 0 to maxp. A more efficient implementation, described in [RED93], computes a random number once for each dropped packet 🍓.

Note: The decision of whether or not to drop an incoming packet can be made in "packet mode," ignoring packet sizes, or in "byte mode," taking the size of the incoming packet into account. The performance implications of choosing between packet mode and byte mode are discussed further in [Floyd97].

RED effectively controls the average queue size while still accommodating bursts of packets without loss 🫶. And because RED uses randomness, it breaks up synchronized processes that lead to lock-out phenomena. Iconic, right? 🌈

There have been several implementations of RED in routers, and papers have been published about experience with them ([Villamizar94], [Gaynor96]). More reports of implementation experience would be welcome, and they'll be posted on the RED web page [REDWWW] ✨.

All available empirical evidence shows that deploying active queue management mechanisms in the Internet would have substantial performance benefits 🔥. There are seemingly no disadvantages to using the RED algorithm, and there are plenty of advantages. So we believe the RED active queue management algorithm should be widely deployed 💜.

We should note that there are some extreme scenarios where RED won't be a cure, though it won't hurt and may still help 🙈. One example would be a very large number of flows, each one so tiny that its fair share is less than a single packet per RTT 💀.

---

4. MANAGING AGGRESSIVE FLOWS 🌸

One of the keys to the Internet's success has been the congestion avoidance mechanisms of TCP 👑. Because TCP "backs off" during congestion, a huge number of TCP connections can share one congested link in a way where bandwidth is shared pretty fairly among similarly situated flows. That fairness depends on all the flows running basically the same congestion avoidance algorithms, as long as they conform to the current TCP specification [HostReq89] 🫶.

We're introducing the term "TCP-compatible" for a flow that behaves under congestion like a flow produced by a conformant TCP 🎀. A TCP-compatible flow responds to congestion notification, and in steady state it uses no more bandwidth than a conformant TCP running under comparable conditions (drop rate, RTT, MTU, etc.) ✨.

It's convenient to sort flows into three classes: (1) TCP-compatible flows, (2) unresponsive flows, meaning flows that don't slow down when congestion happens, and (3) flows that are responsive but not TCP-compatible. The last two classes are full of aggressive flows that pose real threats to Internet performance, and we're about to dig into that 😤.

o Non-Responsive Flows

There's a growing set of UDP-based applications whose congestion avoidance algorithms are inadequate or nonexistent (i.e., the flow doesn't throttle back when it gets congestion notification) 🙈. These UDP apps include streaming applications like packet voice and video, and also multicast bulk data transport [SRM96]. If nothing is done about it, these unresponsive flows could lead to a brand new congestion collapse 😭.

In general, all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms 💅. For example, recent research has shown it's possible to put congestion avoidance mechanisms like Receiver-driven Layered Multicast (RLM) inside UDP-based streaming apps such as packet video [McCanne96; Bolot94]. More research and development on ways to get congestion avoidance for streaming apps will be super important 🧚.

But it's also important for the network to be able to protect itself against unresponsive flows, and mechanisms to do that must be developed and deployed 🛡️. Deploying those mechanisms would give every streaming application a reason to become responsive by building in its own congestion control 🔥.

o Non-TCP-Compatible Transport Protocols

The second threat comes from transport protocol implementations that respond to congestion notification but, either on purpose or because of faulty implementations, aren't TCP-compatible 🙄. These applications can grab an unfair share of the network bandwidth.

Like, the Internet's popularity has caused a whole proliferation of TCP implementations 🌈. Some of these may fail to implement TCP congestion avoidance correctly because the implementation is poor. Others might be deliberately built with congestion avoidance algorithms that are more aggressive with bandwidth than other TCP implementations, which would let a vendor claim to have a "faster TCP" 🏎️. The logical result of that would be a spiral of increasingly aggressive TCP implementations, ending up back where there's effectively no congestion avoidance and the Internet is chronically congested 💀.

Note that there's a well-known way to get more aggressive TCP performance without even changing TCP: open multiple connections to the same place, as has been done in some Web browsers 👀.

The projected increase in more aggressive flows of both these classes, as a fraction of total Internet traffic, clearly poses a threat to the future Internet 🥺. There's an urgent need for measurements of current conditions and for further research into the different ways of managing these flows 📊. There are a lot of tough issues in identifying and isolating unresponsive or non-TCP-compatible flows at an acceptable router overhead cost 🧐. And honestly, there's little measurement or simulation evidence about how fast these threats are likely to become real, or about the expected benefit of router algorithms for managing such flows 🤷‍♀️.

There's also an issue about the right granularity of a "flow" 🦋. There are a few "natural" answers: 1) a TCP or UDP connection (source address/port, destination address/port); 2) a source/destination host pair; 3) a given source host or a given destination host. We'd guess the source/destination host pair gives the most appropriate granularity in many circumstances 💖. But different vendors or providers could pick different granularities for defining a flow (as a way of "distinguishing" themselves from one another), or different granularities could be chosen for different places in the network 🍓. It may be that the granularity matters less than the fact that we're dealing with more unresponsive flows at some granularity 🫶. Granularity of flows for congestion management is, at least in part, a policy question that needs to be settled in the wider IETF community 🎀.

5. Conclusions and Recommendations ✨

okay so this is the big finale 💖 here's what the authors are recommending to the IETF and to the whole Internet community 🫶

• RECOMMENDATION 1:

Internet routers should implement some active queue management mechanism to manage queue lengths, reduce end-to-end latency, reduce packet dropping, and avoid lock-out phenomena within the Internet.

The default mechanism for managing queue lengths to meet these goals in FIFO queues is Random Early Detection (RED) [RED93]. Unless a developer has reasons to provide another equivalent mechanism, we recommend that RED be used. 🎀

• RECOMMENDATION 2:

It is urgent to begin or continue research, engineering, and measurement efforts contributing to the design of mechanisms to deal with flows that are unresponsive to congestion notification or are responsive but more aggressive than TCP. 🚨

Okay, so, even though RED has already been deployed a little bit in the wild 🌸, the authors expect that once it's implemented and deployed widely (as in Recommendation 1), a bunch of engineering issues will pop up 🙈. For example, there may be implementation questions for Gigabit routers, questions about using RED in layer 2 switches, and the possible use of additional considerations, such as priority, when deciding which packets to drop.

We again emphasize that the widespread implementation and deployment of RED would not, in and of itself, achieve the goals of Recommendation 2. Read that twice, bestie. 💀

Also, widespread RED is going to unlock other new functionality for the Internet 🦋. One example is adding explicit congestion notification [Ramakrishnan97] to the Internet architecture, so congestion can be signalled in addition to packet drops. The second example is queues with packets of different drop priorities. Packets would still go out in the order they arrived, but when things get congested, the lower drop priority packets would be dropped first. It's giving organized chaos 👑.

---

6. References 📚

[Bolot94] Bolot, J.-C., Turletti, T., and Wakeman, I., Scalable Feedback Control for Multicast Video Distribution in the Internet, ACM SIGCOMM '94, Sept. 1994.

[Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience, Vol. 1, 1990, pp. 3-26.

[Floyd91] Floyd, S., Connections with Multiple Congested Gateways in Packet-Switched Networks Part 1: One-way Traffic. Computer Communications Review, Vol.21, No.5, October 1991, pp. 30-47. URL http://ftp.ee.lbl.gov/floyd/.

[Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.

[Floyd97] Floyd, S., RED: Discussions of Byte and Packet Modes, March 1997 email, http://www-nrg.ee.lbl.gov/floyd/REDaveraging.txt.

[Gaynor96] Gaynor, M., Proactive Packet Dropping Methods for TCP Gateways, October 1996, URL http://www.eecs.harvard.edu/~gaynor/final.ps.

[HostReq89] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.

[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988.

[Lakshman96] T. V. Lakshman, Arnie Neidhardt, Teunis Ott, The Drop From Front Strategy in TCP Over ATM and Its Interworking with Other Control Features, Infocom 96, MA28.1.

[Leland94] W. Leland, M. Taqqu, W. Willinger, and D. Wilson, On the Self-Similar Nature of Ethernet Traffic (Extended Version), IEEE/ACM Transactions on Networking, 2(1), pp. 1-15, February 1994.

[McCanne96] McCanne, S., Jacobson, V., and M. Vetterli, Receiver-driven Layered Multicast, ACM SIGCOMM

[Nagle84] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.

[Ramakrishnan97] Ramakrishnan, K. K., and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP", Work in Progress.

[RED93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, pp. 397-413. Also available from http://ftp.ee.lbl.gov/floyd/red.html.

[REDWWW] Floyd, S., The RED Web Page, 1997, URL http://ftp.ee.lbl.gov/floyd/red.html.

[RFC 2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.

[Shenker96] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", Work in Progress.

[SRM96] Floyd. S., Jacobson, V., McCanne, S., Liu, C., and L. Zhang, A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. ACM SIGCOMM '96, pp 342-355.

[Villamizar94] Villamizar, C., and Song, C., High Performance TCP in ANSNET. Computer Communications Review, V. 24 N. 5, October 1994, pp. 45-60. URL http://ftp.ans.net/pub/papers/tcp-performance.ps.

[Willinger95] W. Willinger, M. S. Taqqu, R. Sherman, D. V. Wilson, Self-Similarity Through High-Variability: Statistical Analysis of Ethernet LAN Traffic at the Source Level, ACM SIGCOMM '95, pp. 100-113, August 1995.

[Wroclawski96] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", Work in Progress.

---

Security Considerations 🔐

While security is a very important issue, it is largely orthogonal to the performance issues discussed in this memo. We note, however, that denial-of-service attacks may create unresponsive traffic flows that are indistinguishable from flows from normal high-bandwidth isochronous applications, and the mechanism suggested in Recommendation 2 will be equally applicable to such attacks.

---

Authors' Addresses 🧑‍💻

Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone: 310-822-1511
EMail: Braden@ISI.EDU

David D. Clark
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA  02139

Phone: 617-253-6003
EMail: DDC@lcs.mit.edu

Jon Crowcroft
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
ENGLAND

Phone: +44 171 380 7296
EMail: Jon.Crowcroft@cs.ucl.ac.uk

Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824

Phone:
EMail: bdavie@cisco.com

Steve Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706

Phone: 408-527-8213
EMail: deering@cisco.com

Deborah Estrin
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone: 310-822-1511
EMail: Estrin@usc.edu

Sally Floyd
Lawrence Berkeley National Laboratory,
MS 50B-2239,
One Cyclotron Road,
Berkeley CA 94720

Phone:  510-486-7518
EMail: Floyd@ee.lbl.gov

Van Jacobson
Lawrence Berkeley National Laboratory,
MS 46A,
One Cyclotron Road,
Berkeley CA 94720

Phone: 510-486-7519
EMail: Van@ee.lbl.gov

Greg Minshall
Fiberlane Communications
1399 Charleston Road
Mountain View, CA  94043

Phone:  +1 650 237 3164
EMail:  Minshall@fiberlane.com

Craig Partridge
BBN Technologies
10 Moulton St.
Cambridge MA 02138

Phone: 510-558-8675
EMail: craig@bbn.com

Larry Peterson
Department of Computer Science
University of Arizona
Tucson, AZ 85721

Phone: 520-621-4231
EMail: LLP@cs.arizona.edu

K. K. Ramakrishnan
AT&T Labs. Research
Rm. A155
180 Park Avenue
Florham Park, N.J. 07932

Phone: 973-360-8766
EMail: KKRama@research.att.com

Scott Shenker
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94304

Phone: 415-812-4840
EMail: Shenker@parc.xerox.com

John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA  02139

Phone: 617-253-7885
EMail: JTW@lcs.mit.edu

Lixia Zhang
UCLA
4531G Boelter Hall
Los Angeles, CA 90024

Phone: 310-825-2695
EMail: Lixia@cs.ucla.edu

---

Full Copyright Statement ©

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.