RFC 6789
Congestion Exposure (ConEx) Concepts and Use Cases
RFC 6789: Congestion Exposure (ConEx) Concepts and Use Cases 🦋
okay bestie, this is RFC 6789 💖 It's titled Congestion Exposure (ConEx) Concepts and Use Cases, and it's Informational, not a Standards Track spec. It was published in December 2012 and it's part of the ISSN 2070-1721 series. The authors are B. Briscoe, Ed. (BT), R. Woundy, Ed. (Comcast), and A. Cooper, Ed. (CDT). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🧚
Abstract ✨
This doc is the starting point for the whole Congestion Exposure (ConEx) protocol crew 💅 It explains why ConEx puts a marking at the IP layer, which is to expose information about congestion to network nodes. There are a bunch of ways that info could be used, but this one focuses on how the ConEx marking can power way more efficient and effective traffic management than what the Internet has today 🔥
Status of This Memo 🌸
Okay, so the status part is pretty straightforward. This document is not an Internet Standards Track spec. It's just published for info purposes 📚
It's a product of the Internet Engineering Task Force (IETF), so it totally reflects what the IETF community agrees on. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 🙈
If you want the current status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc6789 🎀
Copyright Notice 💜
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc 🧐 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, just like the Simplified BSD License says 🫶
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5
2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 6
2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Core Use Case: Informing Traffic Management . . . . . . . . . 7
3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 7
3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 9
3.3. Comparison with Existing Approaches . . . . . . . . . . . 9
4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11
5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 12
6. Experimental Considerations . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . . 151. Introduction ✨
Okay so the whole magic of Internet tech is that it shares capacity using packets instead of dedicated circuits 💅 Operators try to provide enough shared capacity, but when there's way too much packet load and not enough room, congestion happens 😭 It shows up as more delay, dropped packets, or packets that get explicitly marked with Explicit Congestion Notification (ECN) markings [RFC3168]. As Figure 1 shows, congestion control right now depends on the transport receiver spotting these 'Congestion Signals' and telling the transport sender in 'Congestion Feedback Signals'. The sender is then supposed to slow its rate in response 🐢
This doc is the entry point to the ConEx documentation. It's all about why ConEx needs a marking at the IP layer 🌈 (A companion doc, [CONEX-ABS], is the one that gets into the mechanics of the protocol.) The big idea is that the sender keeps signaling its expected congestion in the headers of whatever data it sends. Mostly, it does this by relaying the 'Congestion Feedback Signals' back into the IP layer. Those signals then travel unchanged across the network to the receiver (shown as 'IP-Layer-ConEx-Signals' in Figure 1). That means IP-layer devices on the path can see info about the whole-path congestion 👀
,---------. ,---------.
|Transport| |Transport|
| Sender | . |Receiver |
| | /|___________________________________________| |
| ,-<---------------Congestion-Feedback-Signals--<--------. |
| | |/ | | |
| | |\ Transport Layer Feedback Flow | | |
| | | \ ___________________________________________| | |
| | | \| | | |
| | | ' ,-----------. . | | |
| | |_____________| |_______________|\ | | |
| | | IP Layer | | Data Flow \ | | |
| | | |(Congested)| \ | | |
| | | | Network |--Congestion-Signals--->-' |
| | | | Device | \| |
| | | | | /| |
| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |
| | | | / | |
| |_____________| |_______________ / | |
| | | | |/ | |
`---------' `-----------' ' `---------'Figure 1: The ConEx Protocol in the Internet Architecture 🧩
Here's the real payoff of putting this info at the IP layer: network operators can use it as input for their traffic management. A ConEx-enabled sender signals its expected whole-path congestion, which is roughly the congestion that the receiver reported back to the sender at least one round-trip time earlier (Figure 1). The ConEx signal is a mark in the IP header, and any IP device can read it easily 🙌 So a node doing traffic management can count congestion as easily as it counts data volume today, just by counting the packets that carry ConEx markings 🔢
ConEx-based traffic management can make super efficient use of capacity ⭐ When there's no congestion, all the traffic management restraints can come off, so the network's full capacity is there for everyone 🌸 And if some users cause disproportionate congestion, the traffic management function can learn about it and directly limit those users' traffic, which protects everyone else sharing that capacity 🛡️ That's why ConEx-based traffic management is a step change in the options operators have for running their networks 💜
The rest of this doc explains the concepts behind ConEx and how exposing congestion can seriously improve Internet traffic management, along with other benefits 💅 Section 2 introduces the concepts you need to get how ConEx-based traffic management works. Section 3 shows how ConEx gets used for traffic management, talks about extra benefits, and compares ConEx-based traffic management to the existing approaches. Section 4 covers other related use cases. Section 5 briefly talks about deployment arrangements. Section 6 suggests open issues that experiments with ConEx could be designed to answer. The final sections are the usual RFC back matter 📎
The rest of the core ConEx doc suite is:
- [CONEX-ABS], which provides an abstract encoding of ConEx signals, explains the ConEx audit and security mechanisms, and describes incremental deployment features;
- [CONEX-DESTOPT], which specifies the IPv6 destination option encoding for ConEx;
- [TCP-MOD], which specifies TCP-sender modifications for use of ConEx;
- and the following documents, which describe some feasible scenarios for deploying ConEx:
- [CONEX-DEPLOY], which describes a scenario around a fixed broadband access network;
- [CONEX-MOBILE], which describes a scenario around a mobile communications provider;
- [CONEX-DATA], which describes how ConEx could be used for performance isolation between tenants of a data centre.
2. Concepts 💡
ConEx depends on a precise definition of congestion, plus a few newer concepts introduced in this section 🧠 All the definitions are summarized in Section 2.4.
2.1. Congestion 🌧️
Despite its central role in network control and management, congestion is remarkably hard to define 😵💫 Experts from different disciplines and perspectives define congestion in a bunch of different ways [Bauer09].
For ConEx, congestion is expressed as the probability of packet loss (or the probability of packet marking if ECN is in use). This definition focuses on how congestion is measured, rather than describing congestion as a condition or state 📏
2.2. Congestion-Volume 📦
The metric ConEx exposes is the congestion-volume: the volume of bytes dropped or ECN-marked in a given period of time. Counting congestion-volume makes each user responsible for their own contribution to congestion 🙋♀️ Congestion-volume can only be a property of traffic, whereas congestion can be a property of traffic or a property of a link or a path.
Let's do a simple example 🎀 Imagine Alice sends 1 GB of a file while the loss-probability is a constant 0.2%. Her contribution to congestion -- her congestion-volume -- is 1 GB x 0.2% = 2 MB. If she then sends another 3 GB of the file while the loss-probability is 0.1%, that adds 3 MB to her congestion-volume. Her total contribution to congestion is then 2 MB + 3 MB = 5 MB 🧮
Good news: measuring Alice's congestion-volume on a real network doesn't need the kind of arithmetic shown above 🙌 Congestion-volume can be measured directly by counting the total volume of Alice's traffic that gets discarded or ECN-marked. (A queue with varying percentage loss does these multiplications and additions inherently.) So with ConEx, network operators can count congestion-volume with techniques that are very similar to the ones they already use for counting volume 🥰
2.3. Rest-of-Path Congestion ✨
okay so bestie, this one is about where congestion is left to go 🦋. At a particular measurement point in a network, "rest-of-path congestion" (aka "downstream congestion") is the level of congestion a traffic flow is expected to hit between that measurement point and its final destination. And "upstream congestion" is the congestion it already hit up to that point. 🌸
Here's the lowkey clever part 💅. If the traffic is ECN-capable, the ECN signals you see in the middle of the network tell you the congestion so far on the path (that's the upstream congestion). The ConEx signals stuffed into IP headers (see Figure 1) tell you the congestion across the whole path, from transport source to transport destination. So if a measurement point sees both, it can subtract the ECN level (upstream) from the ConEx level (whole path) and get a measure of what packets are likely to face between the monitoring point and their destination. That's rest-of-path congestion, and it's giving main character energy 👑. A measurement point can work this out in the aggregate, across all flows. ✨
Now the catch 🙈. A network monitor can usually measure upstream congestion accurately only if the traffic it sees is ECN-capable. [CONEX-ABS] goes deeper into what the network can and can't measure in these situations. BUT, and this is the slay part 🎀, there are a bunch of early deployment setups that still get the benefits of ConEx even without ECN. Those are covered in Section 5. 💖
2.4. Definitions 📖
Okay, time for the glossary, bestie 🧚. Here's everything, no cap:
Congestion: In general, congestion happens when any user's traffic takes a hit from loss, ECN marking, or increased delay because one or more network resources got overloaded. For ConEx specifically, congestion is measured using the concrete signals from loss and ECN markings. Delay is not considered, so it's not part of the picture 🙅♀️. Congestion is measured as the probability of loss or the probability of ECN marking, and it's usually written as a dimensionless percentage. 💜
Congestion-volume: For any granularity of traffic (packet, flow, aggregate, link, etc.), this is the volume of bytes dropped or ECN-marked in a given period of time. Conceptually, it's data volume multiplied by the congestion each packet of that volume experienced. It's usually expressed in bytes (or kB, MB, etc.). 🍓
Congestion policer: A logical entity that lets a network operator monitor each user's congestion-volume and enforce congestion-volume limits (more on this in Section 3.1). 🎀
Rest-of-path congestion (or downstream congestion): The congestion a flow of traffic is expected to experience on the rest of its path. Put differently, at a measurement point in the network, rest-of-path congestion is the congestion the flow has yet to experience as it travels from that point to the receiver. Upstream congestion is usually expressed as a dimensionless percentage. 🌈 (Yes, the original says upstream here, and that's how it's written, iykyk 🙈.)
Upstream congestion: The accumulated congestion a traffic flow has experienced thus far, relative to a point along its path. In other words, at a measurement point, upstream congestion is the accumulated congestion the flow has experienced as it travels from the sender to that point. At the receiver, this is equivalent to the end-to-end congestion level that (usually) gets reported back to the sender. It's usually expressed as a dimensionless percentage. 🦋
Network operator (or provider): The operator of a residential, commercial, enterprise, campus, or other network. 🏠
User: The contractual entity that represents an individual, household, business, or institution that uses the service of a network operator. There's no implication that the contract has to be commercial. For instance, the users of a university or enterprise network could be students or employees who don't pay for access, but who may still be required to follow some form of contract or acceptable use policy. There's also no implication that every user is an end user. Where two networks form a customer-provider relationship, the term "user" applies to the customer network. 🎓
[CONEX-ABS] gives further definitions for aspects of ConEx related to protocol mechanisms. 🧚
- Core Use Case: Informing Traffic Management 🚦
This section explains how ConEx could be the basis for traffic management, highlights extra benefits from having ConEx-aware nodes on the network, and compares ConEx-based traffic management to existing approaches. It's giving strategy, bestie 💅.
3.1. Use Case Description ✨
One of the biggest benefits ConEx can deliver is helping network operators manage traffic on their networks better. Picture the super common case of a commercial broadband network where a relatively small number of users put disproportionate demand on network resources, and that sometimes causes congestion. 😭 The operator wants a way to manage traffic so that the traffic contributing more to congestion bears more of the brunt of the management. 💀
Assuming ConEx signals are visible at the IP layer, the operator can do this by placing a congestion policer at an enforcement point in the network and configuring it with a traffic management policy that monitors each user's contribution to congestion. As described in [CONEX-ABS] and elaborated in [CongPol], one way to implement a congestion policer is similar to a bit-rate policer, except it monitors congestion-volume (based on IP-layer ConEx signals) instead of bit rate. When it's implemented as a token bucket, the tokens give users the right to cause bits of congestion-volume, rather than to send bits of data volume. The fill rate represents each user's congestion-volume quota. 🪣
The congestion policer monitors the ConEx signals of the traffic entering the network. As long as the network stays uncongested and users stay within their quotas, no action is taken. 🫶 When the network becomes congested and a user runs out of quota, some action is taken against the traffic that broke the quota, following the operator's traffic management policy. For example, that traffic may be dropped, delayed, or marked with a lower QoS class. So traffic is managed according to its contribution to congestion, not some application- or flow-specific policy, and it isn't managed at all when there's no congestion. Iconic, honestly 👑.
Here's an example of how an operator might use a ConEx-based traffic management system, using a typical DSL network architecture (as elaborated in [TR-059] and [TR-101]). Traffic is routed from regional and global IP networks to an operator-controlled IP node called the Broadband Remote Access Server (BRAS). From the BRAS, traffic is delivered to access nodes. The BRAS has enhanced functionality, including IP QoS and traffic management capabilities. 🧠
By deploying a congestion policer at the BRAS, the operator can measure the congestion-volume created by users within the access nodes, and police misbehaving users before their traffic affects others on the access network. The policer would be provisioned with a traffic management policy, perhaps directing the BRAS to drop packets from users who exceed their congestion-volume quotas during times of congestion. Those users' apps would likely react the typical way to drops, backing off (assuming at least some use TCP), and that lowers the users' congestion-volumes back within their quota limits. 🌷 If none of a user's apps responds, the policer would keep increasing focused drops and effectively enforce its own congestion control. 🔨
3.2. Additional Benefits 🎁
The ConEx-based approach to traffic management has a bunch of benefits beyond efficiently managing traffic. It gives users incentives to use "scavenger" transport protocols, such as the Low Extra Delay Background Transport [LEDBAT]. These let bulk-transfer applications rapidly yield when interactive applications need capacity (so they "scavenge" leftover bandwidth). 🦋 With a congestion policer in place as described in Section 3.1, users of these protocols are less likely to run afoul of the operator's traffic management policy than users whose bulk-transfer apps send the same volume of traffic without being sensitive to congestion. In short, two users who produce similar traffic volumes over the same time interval may produce different congestion-volumes if one is using a scavenger transport protocol and the other isn't. In that situation, the scavenger user's traffic is less likely to be managed by the operator. 💖
ConEx-based traffic management also lets a user control the relative performance of its own traffic flows. If a user wants some flows to have more bandwidth than others, it can reduce the rate of some traffic so it consumes less of its congestion-volume "budget". That leaves more congestion-volume "budget" for the user to "spend" on making other traffic go faster. 🏎️ This approach is most relevant if congestion is signalled by ECN, because no impairment due to loss is involved and delay can stay low. 🌈
3.3. Comparison with Existing Approaches 💅
Okay bestie, so network operators already have a bunch of ways to deal with congestion and the way a small group of users hogs all the scarce capacity 😭. Most of them fall into three buckets: rate-based, volume-based, or application-based 🎀.
Rate-based approaches limit the traffic rate per user or per network. A user's peak rate and average (or "committed") rate may be capped. The tea is that these can either over-constrain the network, squashing rates even when it isn't congested, or under-constrain it, not squashing them enough during heavy usage periods 🙈.
Round-robin scheduling and fair queuing were built to fix exactly these problems ✨. They even out relative rates between active users (or flows) at a known bottleneck. The bit rate any one user gets depends on how many active users there are at each instant. The catch? They have no memory of usage, so over time they end up favouring heavy users over light users. Not iconic 💀.
Why? These approaches share bit rate instant by instant. But heavy users are active at every instant, whereas light users only occupy their share of the link occasionally 🦋.
Volume-based approaches measure the overall volume of traffic a user sends (and/or receives) over time. Users might hit an absolute volume cap (for example, 10GB per month), or the "heaviest" users might be sanctioned in some other way 🌸. Lots of providers use monthly volume limits and count volume whether or not the network is congested, which creates the potential for over- or under-constraining problems, just like the original rate-based approaches. Same problem, new outfit 👑.
ConEx-based approaches, by comparison, only react during times of congestion and in proportion to each user's congestion contribution. That makes better use of capacity and more proportionate management decisions. Iconic behaviour 🫶.
Unlike ConEx-based approaches, neither rate-based nor volume-based approaches give applications any incentive to use scavenger transport protocols. They may even penalise users of applications that use scavenger transports for the big volume they send, instead of rewarding them for carefully avoiding congestion while sending it. Rude 😤. The volume-based approach in "Comcast's Protocol-Agnostic Congestion Management System" [RFC6057] tries to fix the over-/under-constraining problem by only measuring volume and triggering traffic management action during periods of high utilization. But it still doesn't incentivise scavenger transports, because congestion-causing volume can't be told apart from volume overall. ConEx can do that ✨.
Application-based approaches use deep packet inspection or other techniques to figure out which application a given traffic flow is associated with. Operators can then use that to rate-limit or otherwise sanction certain applications, sometimes only during peak hours. These approaches clash with IPsec and some application-layer encryption, and they may raise additional policy concerns 🚩. In contrast, ConEx offers an application-agnostic metric to base traffic management decisions on 💖.
The existing approaches also share one more limitation that ConEx can help overcome: performance uncertainty. Flat-rate pricing plans are popular because people love knowing their monthly bill stays the same each billing period, so they can plan their costs 💜. But while flat-rate pricing avoids billing uncertainty, it creates performance uncertainty: users can't know whether their connections are being altered or degraded based on how the operator is trying to manage congestion 😭. By exposing congestion information at the IP layer, ConEx provides a metric that can be the open, transparent basis for traffic management policies that both providers and their customers can measure and verify 🔥. It can reduce the performance uncertainty some users currently experience, without sacrificing their billing certainty. Main character energy for everyone 👑.
4. Other Use Cases 🌈
ConEx information can be put to a bunch of uses other than informing traffic management. These include:
- Informing inter-operator contracts: ConEx information is made visible to every IP node, including border nodes between networks. Network operators can use ConEx combined with ECN markings to measure how much traffic from each network contributes to congestion in the other. So congestion-volume could be included as a metric in inter-operator contracts, just as volume or bit rate are included today. This would not be an initial deployment scenario, unless ECN became widely deployed.
- Enabling more efficient capacity provisioning: Section 3.2 explains how operators can use ConEx-based traffic management to encourage use of scavenger transport protocols, which significantly improves the performance of interactive applications while still allowing heavy users to transfer high volumes. Here we explain how this can also benefit network operators.
Today, when loss, delay, or average utilization exceeds a certain threshold, some operators just buy more capacity without attempting to manage the traffic. Other operators prefer to limit a minority of heavy users at peak times, but they still eventually buy more capacity when utilization rises.
With ConEx-based traffic management, a network operator should be able to provision capacity more efficiently. An operator could benefit from this in a variety of ways. For example, the operator could add capacity as it would do without ConEx, but deliver better quality of service for its users. Or, the operator could delay adding capacity while delivering similar quality of service to what it currently provides.
5. Deployment Arrangements 🚀
ConEx is designed so that it can be incrementally deployed in the Internet and still be valuable for early adopters. As long as some senders are ConEx-enabled, a network on the path can unilaterally use ConEx-aware policy devices for traffic management. No changes to network forwarding elements are needed, and ConEx still works if there are other networks on the path that are unaware of ConEx marks 🧚.
The above two steps seem to represent a stand-off where neither step is useful until the other has made the first move: i) some sending hosts must be modified to give information to the network, and ii) a network must deploy policy devices to monitor this information and act on it. Nonetheless, the developer of a scavenger transport protocol like LEDBAT does stand to benefit from deploying ConEx. In this case, the developer makes the first move, expecting it will prompt at least some networks to move in response, using the ConEx information to reward users of the scavenger transport protocol 🍓.
On the host side, we have already shown (Figure 1) how the sender piggy-backs ConEx signals on normal data packets to re-insert feedback about packet drops (and/or ECN) back into the IP layer. In the case of TCP, [TCP-MOD] proposes the required sender modifications. ConEx works with any TCP receiver as long as it uses SACK (selective acknowledgment), which most do. There is a receiver optimisation [TCPM-ECN] that improves ConEx precision when using ECN, but ConEx can still use ECN without it. Networks can make use of ConEx even if the implementations of some of the transport protocols on a host do not support ConEx (e.g., the implementation of DNS over UDP might not support ConEx, while perhaps RTP over UDP and TCP will) 🫶.
On the network side, the provider solely needs to place ConEx congestion policers at each ingress to its network, in a similar arrangement to the edge-policed architecture of Diffserv [RFC2475] ✨.
A sender can choose whether to send packets that support ConEx or packets that don't. ConEx-enabled packets bring information to the policer about congestion expected on the rest of the path beyond the policer. Packets that do not support ConEx bring no such information. Therefore, the network will tend to conservatively rate-limit non-ConEx-enabled packets in order to manage the unknown risk of congestion. In contrast, a network doesn't normally need to rate-limit ConEx-enabled packets unless they reveal a persistently high contribution to congestion. This natural tendency for networks to favour senders that provide ConEx information reinforces ConEx deployment 💜.
Feasible initial deployment scenarios exist for a broadband access network [CONEX-DEPLOY], a mobile communications network [CONEX-MOBILE], and a multi-tenant data centre [CONEX-DATA]. The first two of these scenarios are believed to work well without ECN support, while the data center scenario works best with ECN (and ECN can be deployed unilaterally) 🌸.
The above gives only the most salient aspects of ConEx deployment. For further detail, [CONEX-ABS] describes the incremental deployment features of the ConEx protocol and the components that need to be deployed for ConEx to work 📚.
6. Experimental Considerations 🧪
ConEx is initially designed as an experimental protocol because it makes an ambitious change at the interoperability (IP) layer, so no amount of careful design can foresee all the potential feature interactions with other uses of IP. This section identifies a number of questions that would be useful to answer through well-designed experiments:
- Are the compromises that were made in order to fit the ConEx encoding into IP (for example, that the initial design was solely for IPv6 and not for IPv4, and that the encoding has limited visibility when tunnelled [CONEX-DESTOPT]) the right ones?
- Is it possible to combine techniques for distinguishing self-congestion from shared congestion with ConEx-based traffic management such that users are not penalized for congestion that does not impact others on the network? Are other techniques needed?
- In practice, how does traffic management using ConEx compare with traditional techniques (Section 3.3)? Does it give the benefits claimed in Sections 3.1 and 3.2?
- Approaches are proposed for congestion policing of ConEx traffic alongside existing management (or lack thereof) of non-ConEx traffic, including UDP traffic [CONEX-ABS]. Are they strategy-proof against users selectively using both? Are there better transition strategies?
- Audit devices have been designed and implemented to assure ConEx signal integrity [CONEX-ABS]. Do they achieve minimal false hits and false misses in a wide range of traffic scenarios? Are there new attacks? Are there better audit designs to defend against these?
- If ECN deployment remains patchy, are the proposed initial ConEx deployment scenarios (Section 5) still useful enough to kick-start deployment? Is auditing effective when based on loss at a primary bottleneck? Can rest-of-path congestion be approximated accurately enough without ECN? Are there other useful deployment scenarios?
ConEx is intended to be a generative technology that might be used for unexpected purposes unforeseen by the designers. Therefore, this list of experimental considerations is not intended to be exhaustive 🦋💖
7. Security Considerations 🔐
okay bestie, this one is short but it's a whole vibe 💅 This document doesn't specify a mechanism. It just makes the case for congestion exposure at the IP layer. So the security stuff lives in the companion doc that describes the ConEx protocol and the components that would use it, [CONEX-ABS] 🫶
8. Acknowledgments 🌸
a big thank-you to the people who commented on this doc, you literally made it better 🥹 Bob Briscoe was partly funded by Trilogy, a research project (ICT-216372) supported by the European Community under its Seventh Framework Programme. The views expressed here are those of the author only.
The authors would like to thank the many people that have commented on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan, Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis, Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis, Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig, and Stuart Venters. 🎀 If your name got accidentally left off this list, please accept our apologies. We still love you ✨
9. Contributors 🧚
Philip Eardley and Andrea Soppera made helpful text contributions to this document, so they get a major shoutout 📣
The following co-edited this document through most of its life 👑
Toby Moncaster
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge, CB3 0FD
UK
EMail: toby.moncaster@cl.cam.ac.uk
John Leslie
JLC.net
10 Souhegan Street
Milford, NH 03055
US
EMail: john@jlc.net10. Informative References 📚
these are the extra reads that aren't required but are honestly worth a look 🦋 Here's the full list, exactly as written:
[Bauer09] Bauer, S., Clark, D., and W. Lehr, "The Evolution of
Internet Congestion", 2009.
[CONEX-ABS] Mathis, M. and B. Briscoe, "Congestion Exposure
(ConEx) Concepts and Abstract Mechanism", Work
in Progress, October 2012.
[CONEX-DATA] Briscoe, B. and M. Sridharan, "Network Performance
Isolation in Data Centres using Congestion Exposure
(ConEx)", Work in Progress, July 2012.
[CONEX-DEPLOY] Briscoe, B., "Initial Congestion Exposure (ConEx)
Deployment Examples", Work in Progress, July 2012.
[CONEX-DESTOPT] Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6
Destination Option for ConEx", Work in Progress,
September 2012.
[CONEX-MOBILE] Kutscher, D., Mir, F., Winter, R., Krishnan, S.,
Zhang, Y., and C. Bernardos, "Mobile Communication
Congestion Exposure Scenario", Work in Progress,
July 2012.
[CongPol] Briscoe, B., Jacquet, A., and T. Moncaster, "Policing
Freedom to Use the Internet Resource Pool", ReArch
2008 hosted at the 2008 CoNEXT conference ,
December 2008.
[LEDBAT] Shalunov, S., Hazel, G., Iyengar, J., and M.
Kuehlewind, "Low Extra Delay Background Transport
(LEDBAT)", Work in Progress, September 2012.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC6057] Bastian, C., Klieber, T., Livingood, J., Mills, J.,
and R. Woundy, "Comcast's Protocol-Agnostic
Congestion Management System", RFC 6057,
December 2010.
[TCP-MOD] Kuehlewind, M. and R. Scheffenegger, "TCP
modifications for Congestion Exposure", Work
in Progress, May 2012.
[TCPM-ECN] Kuehlewind, M. and R. Scheffenegger, "More Accurate
ECN Feedback in TCP", Work in Progress, July 2012.
[TR-059] Anschutz, T., Ed., "DSL Forum Technical Report
TR-059: Requirements for the Support of QoS-Enabled
IP Services", September 2003.
[TR-101] Cohen, A., Ed. and E. Schrum, Ed., "DSL Forum
Technical Report TR-101: Migration to Ethernet-Based
DSL Aggregation", April 2006.Authors' Addresses 💌
and here are the people who made this happen, with their contact details 💖
Bob Briscoe (editor)
BT
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Richard Woundy (editor)
Comcast
1701 John F Kennedy Boulevard
Philadelphia, PA 19103
US
EMail: richard_woundy@cable.comcast.com
URI: http://www.comcast.com
Alissa Cooper (editor)
CDT
1634 Eye St. NW, Suite 1100
Washington, DC 20006
US
EMail: acooper@cdt.orgthat's the whole doc, babe, we did it 🌈✨
📦 where this page comes from
- ietf: rfc6789 2012-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms