RFC 7713
Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements
1. Introduction ✨
Okay so, title block first, bestie 🎀. This is RFC 7713, titled "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements" 🦋. It was written by M. Mathis (Google, Inc.) and B. Briscoe (BT) back in December 2015 💖. It's marked as Informational, which means it's published for info and is NOT an Internet Standards Track spec 🌸. It doesn't obsolete or update any other RFCs, and it's part of the ISSN 2070-1721 series 💅.
The abstract is the main vibe check 🔥. It says senders can tell the network about the congestion packets in the same flow recently ran into 👑. Right now, network stuff at any layer can signal congestion to the receiver by dropping packets or using Explicit Congestion Notification (ECN) markings, and the receiver passes that back to the sender in transport-layer feedback 🧚. ConEx lets the sender also send that congestion info back into the network in-band at the IP layer, so the total congestion from every element on the path becomes visible to all IP elements along the path 🌈. That could be used for traffic management, which is so iconic 😭. This mechanism is called Congestion Exposure, or ConEx ⭐. The companion doc is RFC 6789, which is the entry point to all the ConEx docs 🫶.
Status of This Memo
Quick reality check: this doc is NOT an Internet Standards Track spec, it's just for information 💀. It's still an IETF product, so it has consensus from the IETF community, got public review, and was approved by the IESG 🎀. Not everything the IESG approves can be a standard, though, so see Section 2 of RFC 5741 for that 🙈. You can find the current status, errata, and feedback info at http://www.rfc-editor.org/info/rfc7713 💜.
Copyright Notice
The copyright belongs to the IETF Trust and the document authors, copyright 2015, all rights reserved 🌸. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date 🦋. Please actually read those, because they spell out your rights and restrictions 💅. Any Code Components pulled from this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as the Simplified BSD License describes 🔥.
1. Introduction 🌸
Okay, now the real stuff 💖. This doc describes an abstract mechanism where, to a first approximation, senders tell the network about the congestion packets hit earlier in the same flow ✨. It is NOT a complete protocol spec, because designing an encoding (like packet formats, codepoint allocations, and so on) is probably going to involve compromises that rule out some uses of the protocol 🙈. The goal here is to give a framework for building and testing algorithms that evaluate the benefits of the ConEx protocol, and to see what the compromises cost in different encoding designs 🧚. This doc lays out the requirements for concrete protocol specs, so it's basically the blueprint 👑.
The companion doc [RFC6789] is the entry point to all the ConEx documentation 🫶. It covers the concepts you need to get why ConEx is useful, plus different ways it could be used 💜.
2. Overview ✨
okay bestie, big picture time 🦋 Transport protocols (the stuff that gets your data where it's going) are always chasing more network capacity 🚀. When things get crowded, network elements send up signals, and the transports are the ones responsible for controlling that congestion [RFC5681]. The more a transport grabs capacity that other people also want, the more congestion signals get pinned on it. Same vibe for users: the more transport sessions a user runs and the longer they keep them open, the more congestion signals get attributed to that user 👀. ConEx's whole goal is making sure those congestion signals are visible and sturdy enough to use, because they're the perfect metric for networks to base traffic management on (and other related stuff) 💅.
Networks flag congestion in three ways: packet loss, ECN marking, or queueing delay 🌸. ECN marking and some packet loss can come from Active Queue Management (AQM), which the network uses to nudge senders into slowing down. Packet loss also just happens when a buffer or some other network resource is completely maxed out. Some experimental transport protocols and TCP variants guess that congestion is coming when queueing delay goes up, but ngl, delay is too vague to be a good congestion metric 🙈. So across this doc and the other ConEx docs, when we say 'congestion signals', we mean only ECN markings and packet losses, since those are the unambiguous ones 💜.
Both kinds of signal take the same route, shown in Figure 1 🛤️. A congested network device sends a signal in the data stream on the forward path to the transport receiver, the receiver passes it back to the sender through transport-level feedback, and then the sender makes some congestion control adjustment ✨.
This document adds a brand new Congestion Exposure signal to the Internet protocol suite 🎀. Roughly speaking, this signal (also drawn in Figure 1) carries the congestion info from the transport sender back down through the internetwork layer, where any internetwork-layer device along the forward path that cares can see it 👑. This document frames the engineering problem of designing the ConEx Signal. Section 3 covers the requirements, Section 4 has some example encodings, and Section 5 describes all of the protocol components 🧚.
This new signal is specifically built to support all kinds of new policy mechanisms for instrumenting, monitoring, or managing traffic 📊. The policy devices aren't drawn in Figure 1, but they could be placed anywhere along the forward data path (see Section 5.4) 🦋.
,---------. ,---------.
|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 Flow of Congestion and ConEx Signals
Here's the tea 🫖: policy devices can change how traffic gets treated, so it's assumed that users, applications, or operating systems have a built-in motivation to understate the congestion they cause 😤. That's why it's important to be able to audit ConEx Signals and to apply enough sanction to discourage cheating of congestion policies 🚨. The general audit approach is to count signals on the forward path and confirm there are never fewer ConEx Signals than congestion signals ✅. A lot of ConEx's design constraints come from needing the audit function to be robust enough. The audit function is described in Section 5.5, but big chunks of this document (and earlier research [Refb-dis]) are driven by audit issues and making that audit sturdy 💪.
The congestion and ConEx Signals in Figure 1 are a bunch of separate events: ECN marks or lost packets, carried in the forward data stream and fed back into the internetwork layer 🌈. The policy and audit functions will most likely act on the accumulated totals of these signals, which we call "volume" 🧁. For example, "traffic volume" is the total number of bytes delivered, optionally over a set time interval and across some aggregate of traffic (like all traffic from a site), while "loss volume" is the total amount of bytes discarded from some aggregate over an interval. The term "congestion-volume" is defined precisely in [RFC6789]. Also, volume per unit time is just average rate, bestie 🤓.
One of ConEx's design goals is that the important policy mechanisms can be implemented per logical link without any per-flow state (see Section 5.4) 🛣️. The trade-off is that per-flow state could be needed to audit ConEx Signals (Section 5.5). That's justified because i) auditing at the edges, with a limited number of flows, enables policy elsewhere, including in the core, without any per-flow state; and ii) auditing can use soft flow state, which doesn't require route pinning 💖.
There's a long-running argument about units of congestion: bytes vs packets (see [RFC7141] and its references) 🥊. Section 4.6 explains why this problem has to be handled carefully. This document doesn't take a strong position on the issue, though it does require that the units of congestion be an explicitly stated property of any proposed encoding, and that the consequences of that design decision get evaluated along with the other aspects of the design 📝.
For ConEx to succeed, the relevant stakeholders each need an incentive to unilaterally start each stage of partial deployment, and that in turn creates incentives for more deployment 🚀. Also, legacy systems that will never get upgraded shouldn't become a blocker for deploying ConEx 🙌. Partial deployment issues are covered in Section 6.
Quick note: ConEx Signals aren't meant for fine-grained congestion control 🙅♀️. They're expected to be most useful on longer time scales and/or at coarser granularity than single microflows. For example, the total congestion a user causes might feed into higher-level policy or accountability functions that encourage better behavior, like sending big batches of data at off-peak times, at lower data rates, or with less aggressive protocols such as Low Extra Delay Background Transport (LEDBAT) [RFC6817]; see [RFC6789] 🌙.
Ultimately, ConEx Signals could give us a way to regulate global Internet congestion 🌍. Ever since the early days of congestion control research, people have worried that nothing stops transport designers from making protocols more and more aggressive, without limit, until we spiral into a "tragedy of the commons" congestion collapse 😱. The "TCP friendly" paradigm was created partly to prevent that failure. But honestly, it doesn't carry much authority anymore, because it has little to say about today's Internet, which has moved beyond the scaling range of standard TCP 📉. So now lots of transports and applications open arbitrarily large numbers of connections or run at arbitrary levels of aggressiveness 🫠. ConEx is basically the IETF admitting it can't regulate this space directly, since it's about the behaviour of users and applications, not individual transport protocols 🙃. What the IETF can do is give network operators the protocol tools to sort out the space themselves, with better bulk traffic management. That should push users and designers of applications and transport protocols to be more mindful about contributing to congestion 🫶.
2.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖.
Here are the ConEx Signals in IP packet headers, going from the sender to the network 📦:
- Not-ConEx: The transport (or at least this packet) is not using ConEx.
- ConEx-Capable: The transport is using ConEx. This is the opposite of Not-ConEx.
- ConEx Signal: A signal in a packet sent by a ConEx-capable transport. It carries at least one of the following signals:
- Re-Echo-Loss: The transport has experienced a loss.
- Re-Echo-ECN: The transport has detected an ECN Congestion Experienced (CE) mark.
- Credit: The transport is building up credit to give advance notice of the risk of packets contributing to congestion, instead of only signalling after inherently delayed feedback of actual congestion ⏳.
- ConEx-Not-Marked: The transport is ConEx-capable but is not signaling Re-Echo-Loss, Re-Echo-ECN, or Credit.
- ConEx-Marked: At least one of Re-Echo-Loss, Re-Echo-ECN, or Credit.
- ConEx-Re-Echo: At least one of Re-Echo-Loss or Re-Echo-ECN.
3. Requirements for the ConEx Abstract Mechanism 📋
heads up, first-time readers: you might wanna skim this section, since it makes way more sense after you've read the whole doc 🧠✨
3. Requirements for the ConEx Abstract Mechanism 💖
3.1. Requirements for ConEx Signals ✨
okay so ideally, a Congestion Exposure Signal would hit all of these requirements 🫶 (perfectionist energy, I love it 💅):
- a. The ConEx Signal SHOULD be visible to internetwork-layer devices all along the path, from the transport sender 🛣️ to the transport receiver 💌. Put another way, it SHOULD be present in the IPv4 or IPv6 header, and in the outermost IP header if you're doing IP-in-IP tunneling 🎀. It MAY need to be visible if other encapsulating headers are used to interconnect networks ✨. Once the transport sender sets it, the ConEx Signal SHOULD be immutable 🔒. And the big takeaway: the chosen ConEx encoding SHOULD pass silently without modification through preexisting networking gear 🧚.
- b. The ConEx Signal SHOULD be useful under only partial deployment 🌸. A minimal deployment SHOULD only require changes to transport senders. Furthermore, partial deployment SHOULD create incentives for more deployment, both for enabling ConEx on more devices and for adding richer features to existing devices 📈. Nonetheless, ConEx deployment need never be universal 🌈. It's anticipated that some hosts and some transports may never support the ConEx protocol, and some networks may never use the ConEx Signals 🙃.
- c. The ConEx Signal SHOULD be timely ⏰. There will be a minimum delay of one RTT, and often longer if the transport protocol sends infrequent feedback (consider Real-time Transport Control Protocol (RTCP) [RFC3550] [RFC6679], for example).
- d. The ConEx Signal SHOULD be accurate and auditable 🔍. The general approach for auditing is to observe the volume of congestion signals and ConEx Signals on the forward data path, then verify that the ConEx Signals do not underrepresent the congestion signals (see Section 5.5).
- e. The ConEx Signals for packet loss and ECN marking SHOULD have distinct encodings, because they're likely to need different auditing techniques 🧐.
- f. Additionally, there SHOULD be an auditable ConEx Credit signal 💜. A sender can use Credit to indicate potential future congestion, for example, as is often seen during startup 🚀. ConEx Credit is intended to overestimate congestion actually experienced across the network.
Real talk: implementing ConEx Signals is already known to entail some compromises 🙈, so all the requirements above are expressed with the keyword "SHOULD" rather than "MUST". The only mandatory requirement is that a concrete protocol description MUST give sound reasoning if it chooses not to meet some requirement 📝.
3.2. Constraints on the Audit Function 🕵️
The role of the audit function and the constraints on it are described in Section 5.5. There is no intention to standardise the audit function. However, it is necessary to lay down the following normative constraints on audit behaviour, so that transport designers know what to design against and implementers of audit devices know what pitfalls to avoid 🍓:
- Minimal False Hits: Audit SHOULD introduce minimal false hits for honest flows 😇.
- Minimal False Misses: Audit SHOULD quickly detect and sanction dishonest flows, ideally on the first dishonest packet 🎯.
- Transport Oblivious: Audit SHOULD NOT be designed around one particular rate response, such as any particular TCP congestion control algorithm or one particular resource-sharing regime such as TCP friendliness [RFC5348]. An important goal is to give ingress networks the freedom to unilaterally allow different rate responses to congestion and different resource sharing regimes [Evol_cc] without having to coordinate with other networks over details of individual flow behaviour 🤝.
- Sufficient Sanction: Audit SHOULD introduce sufficient sanction (e.g., loss in goodput) such that senders cannot gain from understating congestion 🚫.
- Proportionate Sanction: To the extent that the audit might be subject to false hits, the sanction SHOULD be proportionate to the degree to which congestion is understated. If the audit over-punishes, attackers will find ways to harness it into amplifying attacks on others 💀. Ideally the audit should, in the long run, cause the user to get no better performance than they would get by being accurate ⚖️.
- Manage Memory Exhaustion: Audit SHOULD be able to counter state-exhaustion attacks. For instance, if the audit function uses flow state, it should not be possible for senders to exhaust its memory capacity by gratuitously sending numerous packets, each with a different flow ID 🧠.
- Identifier Accountability: Audit SHOULD NOT be vulnerable to 'identity whitewashing', where a transport can label a flow with a new ID more cheaply than paying the cost of continuing to use its current ID [CheapPseud] 🎭.
3.3. Requirements for Non-abstract ConEx Specifications 📜
An experimental ConEx specification SHOULD describe the following protocol details 📋:
Network Layer:
- A. the specific ConEx Signal encodings with packet formats, bit fields, and/or codepoints;
- B. an inventory of invalid combinations of flags or invalid codepoints in the encoding, as well as whether security gateways should normalise, discard, or ignore such invalid encodings, and what values they should be considered equivalent to by ConEx-aware elements;
- C. an inventory of any conflated signals or any other effects that are known to compromise signal integrity;
- D. whether the source is responsible for allowing for the round-trip delay in ConEx Signals (e.g., using a Credit marking), and if so, whether Credit is maintained for the duration of a flow or degrades over time, and what defines the end of the duration of a flow;
- E. a specification for signal units (bytes vs. packets, etc.), any approximations allowed, and the algorithms to do any implied conversions or accounting;
- F. if the units are bytes, a definition of which headers are included in the size of the packet;
- G. how tunnels should propagate the ConEx encoding;
- H. whether the encoding fields are mutable or not, to ensure that header authentication, checksum calculation, etc., process them correctly; a ConEx encoding field SHOULD be immutable end-to-end, then endpoints can detect if it has been tampered with in transit 🕵️♀️;
- I. if a specific encoding allows mutability (e.g., at proxies), then an inventory of invalid transitions between codepoints; in all encodings, transitions from any ConEx marking to Not-ConEx MUST be invalid 🚷;
- J. a statement that the ConEx encoding is only applicable to unicast and anycast and that forwarding elements should silently ignore any ConEx signalling on multicast packets (they should be forwarded unchanged) 📡;
- K. the definition of any extensibility;
- L. backward and forward compatibility and potential migration strategies; in all cases, a ConEx encoding MUST be arranged so that legacy transport senders implicitly send Not-ConEx 🧓;
- M. any (optional) modification to data-plane forwarding dependent on the encoding (e.g., preferential discard, interaction with Diffserv, ECN, etc.); and
- N. any warning or error messages relevant to the encoding ⚠️.
Note regarding item J on multicast: A multicast tree may involve different levels of congestion on each leg. Any traffic management can only monitor or control multicast congestion at or near each receiver. It would make no sense for the sender to try to expose "whole-path congestion" in sent packets, because it cannot hope to describe all the differing congestion levels on every leg of the tree 🌳.
Transport Layer:
- A. a specification of any required changes to congestion feedback in particular transport protocols;
- B. a specification (or, minimally, a recommendation) for how a transport should estimate credits at the beginning of a connection and while it is in progress 🧮;
- C. a specification of whether any other protocol options should (or must) be enabled along with an implementation of ConEx (e.g., at least attempting to negotiate ECN and Selective Acknowledgement (SACK) capability) 🤏;
- D. a specification of any configuration that a ConEx stack may require (or, preferably, confirmation that it requires no configuration); and
- E. a specification of the statistics that a protocol stack should log for each type of marking on a per-flow or aggregate basis 📊.
Security:
- A. an example of a strong audit algorithm suitable for detecting if a single flow is misstating congestion; this algorithm should present minimal false results but need not have optimal scaling properties (e.g., may need per-flow state) 🔐.
- B. an example of an audit algorithm suitable for detecting misstated congestion in a large aggregate (e.g., no per-flow state) 🧺.
- C. a definition of the level of ConEx-Re-Echo and ConEx-Credit signals that will be sufficient to pass audit (see Section 5.5) ✅.
The possibility exists that these specifications overconstrain the ConEx design and can not be fully satisfied 😬. An important part of the evaluation of any particular design will be a thorough inventory of all the ways in which it might fail to satisfy these specifications 🔎.
4. Encoding Congestion Exposure 🦋
Most protocol specifications start with a description of packet formats and codepoints, with their associated meanings. This document does not 🙅♀️. It is already known that choosing the encoding for ConEx is likely to entail some engineering compromises that have the potential to reduce the protocol's usefulness in some settings. For instance, the experimental ConEx encoding chosen for IPv6 [CONEX-DESTOPT] had to make compromises on tunnelling. Rather than making these engineering choices prematurely, this document sidesteps the encoding problem by making it abstract. It describes several different representations of ConEx Signals, none of which are specified to the level of specific bits or codepoints 🧩.
The goal of this approach is to be as complete as possible when discovering the potential usage and capabilities of the ConEx protocol, so we have some hope of making optimal design decisions when choosing the encoding 🌟. Even if experiments reveal particular problems due to the encoding, this document will still serve as a reference model 👑.
4.1. Naive Encoding 💖
okay bestie, for tutorial purposes it's super helpful to look at a naive encoding of ConEx for TCP and similar protocols 🧚. You set a bit (not specified here) in the IP header on each retransmission and on each ECN-signalled window reduction. Network devices along the forward path can see that bit and act on it. For example, any device on the path might limit the rate of all traffic if the rate of marked (congested) packets goes over a threshold. 🌸
This simple encoding is sufficient to illustrate many of the benefits envisioned for ConEx. ngl, at first glance it looks like it could totally motivate people to deploy it 🤩 It's a one-line code change that a small number of OS developers and content providers could unilaterally deploy across a significant fraction of all Internet traffic. However, this encoding does not support auditing, so it would also motivate users and/or applications to misrepresent the congestion that they are causing [RFC3514]. As a consequence, the naive encoding is not likely to be trusted, and thus it creates its own disincentives for deployment. 💀
Nonetheless, this Naive encoding does present a clear mental model of how the ConEx protocol might function under various uses. It's useful for thought experiments where you can stipulate that all participants are honest, and it does illustrate some of the incentives that might be introduced by ConEx. 🎀
4.2. Null Encoding 🦋
In limited contexts, it's possible to implement ConEx-like functions without any signals at all, by measuring rest-of-path congestion directly from TCP headers. The algorithm is to keep at least one RTT of past TCP headers and match each new header against that history to count duplicate data. 🧠
This could implement many ConEx policies without any explicit protocol. It's fairly easy to implement, at least at low rate (e.g., in a software-based edge router). However, it would only be useful in cases where the network operator can see the TCP headers. At the time of writing (2014), those cases are the majority of traffic, because UDP, IPsec, and VPN tunnels are used far less than Secure Socket Layer (SSL) or Transport Layer Security (TLS) over TCP/IP, which do not hide TCP sequence numbers from network devices. 👀 However, anyone specifically trying to avoid the attention of a congestion policy device would only have to hide their TCP headers from the network operator (e.g., by using a VPN tunnel). 🙈
4.3. ECN-Based Encoding 🌈
The re-ECN specification [RE-ECN-TCP] presents an encoding of ConEx in IPv4 and IPv6 that was tightly integrated with ECN encoding, in order to fit into the IPv4 header. Any individual packet may need to represent any ECN codepoint and any ConEx Signal value independently. So, ideally, their encoding should be entirely independent. However, given the limited number of header bits and/or codepoints, re-ECN chooses to partially share codepoints and to re-echo both losses and ECN with just one codepoint. 🫶
The central theme of the re-ECN work is an audit mechanism that provides sufficient disincentives against misrepresenting congestion [RE-ECN-MOTIVATION]. It's analyzed extensively in Briscoe's PhD dissertation [Refb-dis]. For a tutorial background on re-ECN motivation and techniques, see [Re-fb] and [FairerFaster]. 📚
Re-ECN is an example of one chosen set of compromises attempting to meet the requirements of Section 3. The present document takes a step back, aiming to state the ideal requirements so the Internet community can assess whether different compromises might be better. ✨
The problem with re-ECN is that it requires receivers to be ECN enabled in addition to the sender changes. Newer encodings [CONEX-DESTOPT] overcome this problem by being able to represent loss and ECN-based congestion separately. 👑
4.4. Independent Bits 🍓
This encoding involves flag bits, each of which the sender can set independently to indicate one of the following four signals to the network:
ConEx(Not-ConEx): The transport is (or is not) using ConEx with this packet. (Network-layer encoding requirement L in Section 3.3 says the protocol must be arranged so that legacy transport senders implicitly sendNot-ConEx.)Re-Echo-Loss(Not-Re-Echo-Loss): The transport has (or has not) experienced a loss.Re-Echo-ECN(Not-Re-Echo-ECN): The transport has (or has not) experienced ECN-signalled congestion.Credit(Not-Credit): The transport is (or is not) building up congestion credit (see Section 5.5 on the audit function).
A packet with ConEx set, combined with all three of the other flags cleared, implies ConEx-Not-Marked. 🧁
This encoding does not imply any exclusion property among the signals. Multiple types of congestion (ECN, loss) can be signalled on the same ACK, so ideally a ConEx sender would be able to reflect these in the next packet. However, there will be many invalid combinations of flags (e.g., Not-ConEx combined with any of the ConEx-Marked flags), and a malicious sender could use those to gain an advantage against naive policy devices that only check each flag separately. 😈
As long as the packets in a flow have uniform sizes, it doesn't matter whether the units of congestion are packets or bytes. However, if an application sends very irregular packet sizes, it may be necessary for the sender to mark multiple packets to avoid being in technical violation of an audit function measuring in bytes (see Section 4.6). 📏
4.5. Codepoint Encoding 🎀
This encoding involves signaling one of the following five codepoints:
ENUM {Not-ConEx, ConEx-Not-Marked, Re-Echo-Loss, Re-Echo-ECN, Credit}Each named codepoint has the same meaning as in the encoding using independent bits in the previous section. Using any one codepoint implies the negative of all the others. 💅
Inherently, the semantics of most of the enumerated codepoints are mutually exclusive. 'Credit' is the only one that might need to be used in combination with either Re-Echo-Loss or Re-Echo-ECN, but even that requirement is questionable. It must not be forgotten that the enumerated encoding loses the flexibility to signal these two combinations, whereas the encoding with four independent bits is not so limited. Alternatively, two extra codepoints could be assigned to these two combinations of semantics. The comment in the previous section about units also applies. 🤔
4.6. Units Implied by an Encoding 📏
The following comments apply generally to all the other encodings. 🌸
Congestion can be due to exhaustion of bit-carrying capacity or exhaustion of packet-processing power. When a packet is discarded or marked to indicate congestion, there's no easy way to know whether the lost or marked packet signifies bit congestion or packet congestion. The ConEx encodings above that rely on marking packets suffer from the same ambiguity. 🌀
This problem is most acute when audit needs to check that one count of markings matches another. For example, if there are ConEx markings on three large (1500 B) packets, is that enough to match the loss of five small (60 B) packets? If a packet marking is defined to mean all the bytes in the packet are marked, then we have 4500 B of ConEx-Marked data against 300 B of lost data, which is easily sufficient. If instead we count packets, then we have three ConEx packets against five lost packets, which is not sufficient. This problem won't arise when all the packets in a flow are the same size, but a choice needs to be made for flows in which packet sizes vary, such as BGP, SPDY, and some variable-rate video encoding schemes. 🎬
Whether to use bytes or packets is not obvious. For instance, the most expensive links in the Internet, in terms of cost per bit, are all at lower data rates, where transmission times are large and packet sizes matter. In order for a policy to consider wire time, it needs to know the number of congested bytes. However, high speed networking equipment and the transport protocols themselves sometimes gauge resource consumption and congestion in terms of packets. 🤷♀️
[RFC7141] advises that congestion indications should be interpreted in units of bytes when responding to congestion, at least on today's Internet. [RFC6789] takes the same view in its definition of congestion-volume, again for today's Internet. 💜
In any TCP implementation, this is simple to achieve for varying size packets, given that TCP SACK tracks losses in bytes. If an encoding is specified in units of bytes, the encoding should also specify which headers to include in the size of a packet (see network-layer requirement F in Section 3.3). 🧩
RFC 7141 constructs an argument for why equipment tends to be built so that the bottleneck will be the bit-carrying capacity of its interfaces, not its packet-processing capacity. However, RFC 7141 acknowledges that the position may change in future, and it notes that new techniques will need to be developed to distinguish packet and bit congestion. 🔮
Given this document describes an abstract ConEx mechanism, it's intended to be timeless. Therefore, it does not take a strong position on this issue. However, a ConEx encoding will need to explicitly specify whether it assumes units of bytes or packets, consistently for both congestion indications and ConEx markings (see network-layer requirement E in Section 3.3). It may help to refer to the guidance in [RFC7141]. 🦋
5. Congestion Exposure Components ✨
The components shown in Figure 1, as well as policy and audit, are described in more detail here. 🗺️
5.1. Network Devices (Not Modified) 🛜
Congestion signals originate from network devices, just as they do today. A congested router, switch, or other network device can discard or ECN-mark packets when it's congested. 🚦
5.2. Modified Senders 🚀
The sending transport needs to be modified to send Congestion Exposure signals in response to congestion feedback signals (e.g., for the case of a TCP transport, see [TCP-MODIFICATION]). We want to permit ConEx without ECN (e.g., if the receiver does not support ECN). However, we want to encourage a ConEx sender to at least attempt to negotiate ECN (a ConEx transport protocol specification may require this), because it's believed that ConEx without ECN is harder to audit and thus potentially exposed to cheating. Since honest users have the potential to benefit from stronger mechanisms to manage traffic, they have an incentive to deploy ConEx and ECN together. 🫶 This incentive is not sufficient to prevent a dishonest user from constructing (or configuring) a sender that enables ConEx after choosing not to negotiate ECN, but it should be sufficient to prevent this from becoming the sustained default case for any significant pool of users. 🛡️
Permitting ConEx without ECN is necessary to facilitate bootstrapping other parts of ConEx deployment. 🥾
5.3. Receivers (Optionally Modified) 💖
okay so receivers can be totally chill, bestie 💅 Any receiving transport may already feedback sufficiently useful signals to the sender so that it does not need to be altered. Basically, if the receiver is already sending back the right info, it doesn't need a glow-up at all ✨
The native loss or ECN signaling mechanism needed to follow existing congestion control standards (e.g., RTCP, Stream Control Transmission Protocol (SCTP)) will typically be sufficient for the Sender to generate ConEx Signals. So if the transport is already doing its congestion stuff properly, the sender can usually make ConEx Signals from that feedback 🦋
TCP's loss feedback is sufficient for ConEx if SACK is used [RFC2018]. However, the original specification for ECN in TCP [RFC3168] signals congestion no more than once per round trip. ngl this is where it gets a little messy 🙈 The sender may require more precise feedback from the receiver, otherwise it is at risk of appearing to be understating its ConEx Signals. nobody wants to look like they're underreporting their congestion, that's giving unreliable 💀
Ideally, ConEx should be added to a transport like TCP without mandatory modifications to the receiver. But in the TCP-ECN case, an optional modification to the receiver could be recommended for precision (see [RFC7560], which is based on the approach originally taken when adding re-ECN to TCP [RE-ECN-TCP]). So the vibe is: no forced receiver changes, but a little optional upgrade gets you way more precise results 🎀
5.4. Policy Devices 🧚
okay so policy devices are the ones that need to be configured with a policy about the users or neighboring networks they serve. Main character energy, but they need instructions 📋 In contrast, auditing devices only enforce compliance with the ConEx protocol and don't need any client-specific policy. they're the no-drama friend who just checks the rules 🫶
One of the design goals of the ConEx protocol is that none of the important policy mechanisms requires per-flow state, and that policy mechanisms can even be implemented for heavily aggregated traffic in the core of the Internet, with complexity akin to accumulating marking volumes per logical link. literally the goal is that this stays cheap even on huge traffic 🔥 Of course, policy mechanisms may sometimes choose to focus down on individual flows, but ConEx aims to make aggregate policy devices feasible 🌈
5.4.1. Congestion Monitoring Devices 🌸
Policy devices can typically be broken into two functions: i) monitoring the ConEx Signal to compare it with a policy, and then ii) acting in some way on the result. So it's like: watch, compare, react 👀 Various actions might be invoked against 'out of contract' traffic, such as policing (see Section 5.4.3), re-routing, or downgrading the class of service. Yikes, the out-of-contract traffic is not having a good day 💀
Alternatively, a policy device might not act directly on the traffic, but instead report to management systems that are designed to control congestion indirectly. For instance, the reports might trigger capacity upgrades, penalty clauses in contracts, levy charges based on congestion, or merely send warnings to clients who are causing excessive congestion. so the device can be the messenger instead of the bouncer 💅
Nonetheless, whatever action is invoked, the congestion monitoring function will always be a necessary part of any policy device. no monitoring, no policy, periodt ✨
5.4.2. Rest-of-Path Congestion Monitoring 🦋
ConEx Signals indicate the level of congestion along a whole path from source to destination. In contrast, ECN signals monitored in the middle of a network indicate the level of congestion experienced so far on the path (of course, only in ECN-capable traffic). So ConEx is the whole story, and ECN is just the first chapter 📖
If a monitor in the middle of a network (e.g., at a network border) measures both of these signals, it can subtract the level of ECN (path so far) from the level of ConEx (whole path) to derive a measure of the congestion that packets are likely to experience between the monitoring point and their destination (rest-of-path congestion). this subtraction trick is so clever, I'm obsessed 😭🧮
It will often be preferable for policy devices to monitor rest-of-path congestion if they can, because it is a measure of the downstream congestion that the policy device can directly influence by controlling the traffic passing through it. basically the rest-of-path number is the one the device actually has power over, so that's the one to watch 👑
5.4.3. Congestion Policers 🎀
A congestion policer can be implemented in a very similar way to a bit-rate policer, but its effect can be focused solely on traffic of users causing congestion downstream, which ConEx Signals make visible. Without ConEx Signals, the only way to mitigate congestion is to blindly limit the traffic bit-rate, on the assumption that high bit-rate is more likely to cause congestion. so without ConEx you're basically just guessing based on how fast someone's going, which is not it 🙄
A congestion policer monitors all ConEx traffic entering a network or some identifiable subset. Using ConEx Signals and/or Credit signals (and preferably subtracting ECN signals to yield rest-of-path congestion), it measures the amount of congestion that this traffic is contributing somewhere downstream. If this persistently exceeds a policy-configured 'congestion-bit-rate', the congestion policer can limit all the monitored ConEx traffic. hot take: this is the most precise way to be fair to everyone 🍓
A congestion policer can be implemented by a simple token bucket applied to an aggregate. But unlike a bit-rate policer, it removes tokens only when it forwards packets that are ConEx-Marked, effectively treating Not-ConEx-Marked packets as invisible. Consequently, because tokens give the right to send congested bits, the fill rate of the token bucket will represent the allowed congestion-bit-rate. This should provide sufficient traffic management without having to additionally constrain the straight bit-rate at all. See [ISOLATION-POLICING] for details. the bucket only counts the congested bits, so the plain bit-rate gets to live its best life untouched 🧚
Note that the policing action could be to introduce a throttle (discard some traffic) immediately upstream of the congestion monitor. Alternatively, this throttle could introduce delay using a queue with its own AQM, which potentially increases the whole path congestion. In effect, the congestion policer has moved the congestion earlier in the path and focused it on one user to protect downstream resources by reducing the congestion in the rest of the path. ok so the congestion gets moved to one naughty user so everyone else downstream stays happy 🌈💖
5.5. Audit 🕵️♀️✨
okay so the biggest thing about ConEx is that it has to support robust auditing 😭🫶 It's giving "trust but verify." If users get sanctioned based on ConEx Signals, they're going to be super tempted to understate how much congestion they're actually causing 💀 And if nobody's checking, the ConEx Signal just gets understated until it's totally useless 🙃 So honestly, the most important thing to get right in an encoding design is how well it supports auditing 👑
The auditor's whole job is to make sure any ConEx-enabled traffic is sent with enough ConEx-Re-Echo and ConEx-Credit signals 🎀 The ConEx protocol MUST define what "sufficient" actually means, so there's no vibes-based guessing 💅
If a ConEx-enabled transport doesn't carry sufficient ConEx Signals, the auditor will probably hit that traffic with some kind of sanction 🚫 Sanctions are out of scope for this document, but one example would be throttling the traffic just upstream of the auditor so the user can't profit from understating congestion 💸 That kind of throttle would likely involve some mix of delaying and dropping traffic 📉
A ConEx auditor might use one of these techniques ✨
- Generic loss auditing: For congestion signalled by loss, totally accurate auditing isn't believed to be possible in the general case 😩 That's because a network node would have to notice that some packets are missing, and it can't always tell retransmissions or missing packets apart. The missing packet might just be taking a different route, or the IP payload might be encrypted 🔐
- It's honestly why we want to motivate deploying ECN, even though ECN is not strictly required for ConEx 🌈
- ECN auditing: Directly observe and compare the volume of ECN and ConEx marks 📊 The volume of ECN marks rises monotonically along a path, so ECN auditing is most accurate when it's located near the transport receiver 🎯 For this reason, ECN should be monitored downstream of the predominant bottleneck 🧚
- TCP-specific loss auditing: For non-encrypted standard TCP traffic on a single path, a tactical audit approach could be to measure losses by detecting retransmissions 🔍 These show up as duplicate sequence numbers upstream of the loss, and as out of order data downstream of the loss 🌀 Since some reordering happens on the Internet, a loss estimator like this would be most accurate near the sender 🍓 An audit device should treat non-ECN-capable packets with an encrypted IP payload as Not-ConEx, even if they claim to be ConEx-capable 🙈 The exception is if the operator is also using one of the other two techniques below that can audit those packets against losses 🫶
- Predominant bottleneck loss auditing: For networks designed so that losses mostly happen under the control of one IP-aware bottleneck node on the path, the auditor could sit right at that bottleneck 🚧 It could simply compare ConEx Signals with actual local packet discards (and ECN marks) 🧾 This is a great model for most consumer access networks, where audit accuracy could be good enough even if losses occasionally happen somewhere else in the network 🏠
- Sure, the auditor at the predominant bottleneck can't count losses at other nodes 🙃 But transports don't know where losses are happening either, so a transport wouldn't know which losses it could cheat on and which ones it couldn't get away with 👀
- ECN tunnel loss auditing: A network operator can set up IP-in-IP tunnels (or IP-in-MPLS, etc.) so that any losses inside the tunnels get deferred until the tunnel egress 🚇 Then the audit function can be deployed at the egress and know about all the losses 🤯 This works by enabling ECN marking on switches and routers inside a tunnel, no matter whether the end systems support ECN, by exploiting a side effect of how tunnels handle the ECN field 🪄 After encapsulation at the tunnel ingress, the network should arrange for any non-ECN packets (with
00in the ECN field of the outer header) to be set to the ECN-capable transport (ECT(0)) codepoint 🎀 Then, if they hit congestion at one of the ECN-capable switches or routers inside the tunnel, some get ECN-marked instead of immediately dropped 💖 However, when the tunnel decapsulator strips the outer header from such an ECN-marked packet, if it finds the inner header has00in the ECN field (meaning the endpoints don't support ECN), it will automatically drop the packet, assuming it complies with [RFC6040] 😳 So an audit function at the decapsulator can figure out which packets would have been dropped inside the tunnel (and even which are genuinely ECN-marked for the end-to-end protocol) 🔥 Non-ECN end systems outside the tunnel see no sign of the ECN usage happening internally 🫥
Other audit techniques may be identified in the future too, so keep your eyes peeled 👀✨
In addition, other audit techniques may be identified in the future.
[Refb-dis] gives a comprehensive inventory of attacks against audit that various people have proposed 🕵️ It includes pseudocode for both deterministic and statistical audit functions designed to thwart these attacks, and it analyses how effective an implementation is 📚 Even though this work is specific to the re-ECN protocol, most of the material is useful for designing and assessing audit of other specific ConEx encodings, against both ECN and loss 💜
The auditing function should be able to trigger sufficient sanction to discourage understating congestion [Salvatori05] 😤 This seems to mean the sanction has to be designed together with the policy functions, even though they might be implemented in different parts of the network 🧩 However, [Refb-dis] proves that audit and policy functions can be independent, as long as audit drops enough traffic to 'normalise' actual congestion signals so they're no greater than ConEx Signals 🦋
Similarly, the job of incentivising the sending of ConEx-enabled packets belongs solely to policy devices, independent of the audit function 💅 The audit function's job is policy neutral, so it should be solely confined to checking for correctness within the packets that have been marked as ConEx-capable 🫶 Even if there are Not-ConEx packets mixed in with ConEx packets within a flow, audit doesn't need to monitor any of the Not-ConEx packets 🙌
Note that in the future it might prove desirable to provide advice on uniformly implementing sanctions 📝 Otherwise, insufficient sanctions could impair the ability to implement policy elsewhere in the network 😬
Some of the audit algorithms need per-flow state 🧠 This cost is expected to be tolerable, because these techniques are most apropos near the edges of the network, where traffic is generally much less aggregated, so the state doesn't need to overwhelm any one device 🌸 The flow state required for the audit creates itself as the audit detects new flows ✨ So a flow won't fail if it gets re-routed away from the audit box currently holding its flow state 🦋 That means auditing doesn't require route pinning and works fine with multipath flows 🙌
Holding flow state seems to create a vulnerability to attacks that exhaust the auditor's memory by opening loads of new short flows 💀 The audit function can protect itself by not allocating new flow state unless a ConEx-Marked packet arrives (for example, credit at the start of a flow) 🛡️ Because policy devices rate limit ConEx-Marked packets, this sets a natural limit on how fast a source can create flow state in audit devices 🧱 The auditor would treat all the remaining flows without any ConEx-Marked packets as a single misbehaving aggregate 🫠
Auditing can be distributed and redundant 🌐 One flow may be audited in multiple places, using multiple techniques 🔁 Some audit techniques don't require any per-flow state and can be applied to aggregate traffic 📈 These might be able to detect understated congestion at large scale, and support recursively hunting for individual flows that are understating their congestion 🔎 Even at large scales, flows can be randomly selected for individual auditing 🎲
Sampling techniques can also be used to bound the total auditing memory footprint 🧮 But the implementer needs to counter the tactic where a source cheats until it gets caught by sampling, then simply discards that flow ID and starts cheating with a new one (termed 'identifier whitewashing when caught') 🫣
For the concrete ConEx protocol encoding defined in [CONEX-DESTOPT], ConEx Credit and ConEx-Re-Echo signals are intended to be audited separately 🎀 The Credit signal can be audited directly against actual congestion (loss and ECN) 🎯 However, there's an inherent delay of at least one round trip between a congestion signal and the subsequent ConEx-Re-Echo signal it triggers, as shown in Figure 1 ⏳
Therefore, ConEx-Re-Echo signals will need to be audited with some allowance for this delay 🕰️ Further discussion of design and implementation choices for functions intended to audit this concrete ConEx encoding can be found in [CONEX-AUDIT] 📖💖
6. Support for Incremental Deployment ✨
Okay bestie, this part is my favourite because it's all about how ConEx can roll out gradually without breaking everyone's stuff 🌈 The abstract protocol is designed to support incremental deployment in every possible respect. Here's the list of every feature that makes that work in the concrete ConEx specs, with a pointer to where you can read more 🦋
Packets: The wire protocol encoding lets each packet say whether it's using ConEx or not 📦 (check out Section 4 on Encoding Congestion Exposure 💜)
Senders: ConEx needs the source to be modified so it can send ConEx packet markings 🛠️ (see Section 5.2). Even though ConEx support can be indicated packet by packet, it's likely that all the packets in a flow will either consistently support ConEx or consistently not 💅 It's also likely that if a host's transport implementation supports ConEx, then every packet sent from that host using that protocol will be ConEx-Capable 🔥
Some transport implementations on a host might not support ConEx at all. For example, DNS over UDP might not support it, while RTP over UDP and TCP perhaps will 🎀 Any non-upgraded transports and non-upgraded hosts will just keep sending regular Not-ConEx packets like always 🫶
A network operator can create incentives for senders to voluntarily reveal ConEx information 🍓 (see the Networks item below for incremental deployment by networks 👑)
Receivers: A ConEx source should be able to work with the regular receiver for the transport in question without needing any ConEx-specific modifications ✨ This is true for modern transports like RTCP and SCTP, and it's even true for TCP, as long as the receiver supports SACK, which is already widely deployed anyway 🙌 However, it's NOT true for ECN feedback in TCP 💀 The need for more precise ECN feedback in TCP isn't exclusive to ConEx either. Data Centre TCP [DCTCP], for instance, uses precise feedback to good effect 🌸 So if a receiver offers precise feedback [RFC7560], it'll be best if ConEx uses it too (see Section 5.3) 💖
Alternatively, without sufficiently precise congestion feedback from the receiver, the source may have to conservatively send extra ConEx markings so it doesn't understate congestion 🧚
Proxies: Even though it was said above that ConEx requires a modification to the source, ConEx Signals could theoretically be introduced by a proxy for the source, as long as that proxy can intercept feedback from the receiver 🦋 Similarly, more precise feedback could theoretically come from a proxy for the receiver instead of modifying the receiver itself 😭
Forwarding: No modification to forwarding or queuing is needed for ConEx 🎉
That said, once some ConEx is deployed, a queue implementation could optionally take advantage of the ConEx information in packets 👀 For example, it's been suggested [CONEX-DESTOPT] that a queue would be more robust against flooding if it preferentially discarded Not-ConEx packets and then Not-Marked ConEx packets 🛡️
A ConEx sender re-echoes congestion whether or not the queues signalling congestion are ECN enabled 💅 Still, an operator relying on ConEx Signals is recommended to enable ECN in queues wherever possible 🌈 That's because auditing works best when most congestion is indicated by ECN rather than loss (see Section 3) ✨ Also, monitoring rest-of-path congestion isn't accurate if there are congested non-ECN queues upstream of the monitoring point (Section 5.4.2) 🙈
Networks: If a subset of traffic sources (or proxies) use ConEx Signals to reveal congestion in the internetwork layer, a network operator can choose (or not) to use that information for traffic management 👑 As long as the end-to-end ConEx Signals are present, each network can unilaterally choose to use them, independently of whether other networks do 🦋
ConEx-marked packets may safely traverse a network that ignores them 🫶 ConEx Signals are defined to stay unchanged once set by the sender, though some encodings may allow changes in transit (for example, by proxies) 🎀 In no circumstances will a network node change ConEx-Capable packets to Not-ConEx (network-layer encoding requirement I in Section 3.3) 🚫 If necessary, endpoints should be able to detect whether a network is removing ConEx Signals (network-layer encoding requirement H in Section 3.3) 🕵️♀️
An operator can deploy policy devices (Section 5.4) wherever traffic enters its network, so it can monitor the downstream congestion that incoming traffic contributes to and control it if necessary 🌊 A network operator can also create incentives for the developers of sending applications and transports to voluntarily reveal ConEx information 💜 Without ConEx information, an operator tends to have to limit the bit-rate or volume from a site more than is necessary, just in case it might congest others 😩 With ConEx information, the operator can limit only the congestion-causing traffic and otherwise allow complete freedom ✨ That greater freedom is the inducement for the source to volunteer ConEx information 🎁 An operator may also monitor whether a source transport has sent ConEx packets, and treat that same transport with greater suspicion (for example, a more stringent rate limit) whenever it selectively sends packets without ConEx support 👀 See [RFC6789] for further discussion of deployment incentives for networks, and for references to scenarios where some networks use ConEx-based policy devices and others don't 📚
An operator can deploy audit devices (Section 5.5) unilaterally within its own network to verify that traffic sources aren't understating ConEx information 🔍 From the viewpoint of one network operator (say N_a), they only care that the level of ConEx signalling is sufficient to cover congestion in their own network 💅 If traffic continues into a congested downstream network (say N_b), it's of no concern to the first network (N_a) whether the end-to-end ConEx signalling is insufficient to cover the congestion in N_b as well 🙌 That's N_b's concern, and N_b can both detect such anomalous traffic and deal with it using its own ConEx-based audit devices 🫡
7. Security Considerations 🔐
Okay, this section is serious, so buckle up 😭 The only known risk associated with ConEx is that users and applications are very likely to be motivated to underrepresent the congestion they cause 💀 A big chunk of this document is about mechanisms to audit the ConEx Signals and create enough sanction to stop that underrepresentation 🚨 In particular, see Section 5.5 👑
Security attacks and their defences are best discussed against a concrete protocol specification, not the abstract mechanism of this document 🧠 A concrete ConEx protocol will need to be accompanied by a document describing how the protocol and its audit mechanisms defend against likely attacks 🛡️ [Refb-dis] will be a useful source for such a document 📖 It gives a comprehensive inventory of attacks against audit that various parties have proposed 🕷️ It also includes pseudocode for both deterministic and statistical audit functions designed to thwart these attacks, and analyses how effective an implementation is 📊
However, [Refb-dis] is specific to the re-ECN protocol, which signalled ECN and loss together, whereas the concrete ConEx protocol defined in [CONEX-DESTOPT] signals them separately 🧩 So even though the likely attacks will be similar, there will be more combinations of attacks to worry about, and the defences and their analysis are likely to be a little different for ConEx 🌀
The main known attacks that a security document for a concrete ConEx protocol will need to address are listed below 📝 [Refb-dis] should be referred to for how re-ECN was designed to defend against similar attacks 💜
- Attacks on the audit function (see Section 7.5 of [Refb-dis]):
- Flow ID Whitewashing: Designing the audit function so that a source can't gain anything from starting a new flow once audit has detected cheating in a previous flow 🙅♀️
- Dragging Down an Aggregate: Avoiding audit discarding packets from all flows within an aggregate. Otherwise one flow could pull down the average so that the audit function discards packets from all flows, not just the offending one 😤
- Dragging Down a Spoofed Flow ID: An attacker understates ConEx markings in packets that spoof another flow, which fools the audit function into dropping the genuine user's packets 🥺
- Attacks by networks on other networks (see Section 8.2 of [Refb-dis]):
- Dummy Traffic: Sending dummy traffic across a border with understated ConEx markings to bring down the average ConEx markings in the aggregate of border traffic. This attack can be combined with a TTL that expires before the packets reach an audit function 🫠
- Signal Poisoning with 'Cancelled' Marking: Sending high volumes of valid packets that are both ConEx-Marked and ECN-marked. That seems to represent congestion upstream, but it makes these packets immune to being further ECN-marked downstream 🥶
It is planned to document all known attacks and their defences (including all of the above) in the RFC series against a concrete ConEx protocol specification. Until then, [Refb-dis] and its references should be referred to for details and ways to address these attacks in the case of re-ECN 📚⚠️
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References ✨
okay bestie, this is the bibliography, and I'm not gonna pretend it's a vibe 💀 but it's the stuff the authors read to build their ideas, so every single entry stays exactly as it is 📚
[CheapPseud]
Friedman, E. and P. Resnick, "The Social Cost of Cheap
Pseudonyms", Journal of Economics and Management Strategy,
Volume 10, Issue 2, pp. 173-199,
DOI 10.1111/j.1430-9134.2001.00173.x, Summer 2001.
[CONEX-AUDIT]
Wagner, D. and M. Kuehlewind, "Auditing of Congestion
Exposure (ConEx) signals", Work in Progress,
draft-wagner-conex-audit-01, February 2014.
[CONEX-DESTOPT]
Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6
Destination Option for Congestion Exposure (ConEx)", Work
in Progress, draft-ietf-conex-destopt-11, October 2015.
[DCTCP] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel,
P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data
Center TCP (DCTCP)", ACM SIGCOMM Computer Communication
Review, Volume 40, Issue 4, pages 63-74,
DOI 10.1145/1851182.1851192, October 2010,
<http://portal.acm.org/citation.cfm?id=1851192>.
[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and the
evolution of congestion control", Automatica, Volume 35,
Issue 12, pages 1969-1985,
DOI 10.1016/S0005-1098(99)00135-1, December 1999,
<http://www.sciencedirect.com/science/article/pii/
S0005109899001351>.
[FairerFaster]
Briscoe, B., "A Fairer, Faster Internet Protocol", IEEE
Spectrum, pages 38-43, DOI 10.1109/MSPEC.2008.4687368,
December 2008,
<http://spectrum.ieee.org/telecom/standards/
a-fairer-faster-internet-protocol>.
[ISOLATION-POLICING]
Briscoe, B., "Network Performance Isolation using
Congestion Policing", Work in Progress,
draft-briscoe-conex-policing-01, February 2014.
[RE-ECN-MOTIVATION]
Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith,
"Re-ECN: A Framework for adding Congestion Accountability
to TCP/IP", Work in Progress,
draft-briscoe-conex-re-ecn-motiv-03, March 2014.
[RE-ECN-TCP]
Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith,
"Re-ECN: Adding Accountability for Causing Congestion to
TCP/IP", Work in Progress,
draft-briscoe-conex-re-ecn-tcp-04, July 2014.
[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,
Salvatori, A., Soppera, A., and M. Koyabe, "Policing
Congestion Response in an Internetwork Using Re-Feedback",
ACM SIGCOMM Computer Communication Review, Volume 35,
Issue 4, pages 277--288, DOI 10.1145/1090191.1080124,
August 2005,
<http://portal.acm.org/citation.cfm?id=1080091.1080124>.
[Refb-dis] Briscoe, B., "Re-feedback: Freedom with Accountability for
Causing Congestion in a Connectionless Internetwork", PhD
Dissertation, University College London, May 2009,
<http://discovery.ucl.ac.uk/16274/>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<http://www.rfc-editor.org/info/rfc2018>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, DOI 10.17487/RFC3514, April 2003,
<http://www.rfc-editor.org/info/rfc3514>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<http://www.rfc-editor.org/info/rfc5348>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed.,
"Congestion Exposure (ConEx) Concepts and Use Cases",
RFC 6789, DOI 10.17487/RFC6789, December 2012,
<http://www.rfc-editor.org/info/rfc6789>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>.
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion
Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141,
February 2014, <http://www.rfc-editor.org/info/rfc7141>.
[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe,
"Problem Statement and Requirements for Increased Accuracy
in Explicit Congestion Notification (ECN) Feedback",
RFC 7560, DOI 10.17487/RFC7560, August 2015,
<http://www.rfc-editor.org/info/rfc7560>.
[Salvatori05]
Salvatori, A., "Closed Loop Traffic Policing", Politecnico
Torino and Institut Eurecom Masters Thesis, September
2005.
[TCP-MODIFICATION]
Kuehlewind, M. and R. Scheffenegger, "TCP modifications
for Congestion Exposure", Work in Progress, draft-ietf-
conex-tcp-modifications-10, October 2015.Acknowledgments 🫶
this doc got way better thanks to review comments from Toby Moncaster, Nandita Dukkipati, Mirja Kuehlewind, Caitlin Bestler, Marcelo Bagnulo Braun, John Leslie, Ingemar Johansson, and David Wagner 💖 literal legends, all of them 🙌
Bob Briscoe's work on this specification received part-funding from the European Union's Seventh Framework Programme FP7/2007-2013 under the Trilogy 2 project, grant agreement no. 317756. The views expressed here are solely those of the authors 🌸
Authors' Addresses 🎀
the people who wrote it, and how to reach them 💌
Matt Mathis
Google, Inc.
1600 Amphitheater Parkway
Mountain View, California 93117
United States
Email: mattmathis@google.com
Bob Briscoe
BT (now at Simula Research Laboratory)
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/📦 where this page comes from
- ietf: rfc7713 2015-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms