diff options
Diffstat (limited to 'doc/rfc/rfc7713.txt')
| -rw-r--r-- | doc/rfc/rfc7713.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc7713.txt b/doc/rfc/rfc7713.txt new file mode 100644 index 0000000..a1f1ae0 --- /dev/null +++ b/doc/rfc/rfc7713.txt @@ -0,0 +1,1683 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Mathis +Request for Comments: 7713 Google, Inc. +Category: Informational B. Briscoe +ISSN: 2070-1721 BT + December 2015 + + + Congestion Exposure (ConEx) Concepts, Abstract Mechanism, + and Requirements + +Abstract + + This document describes an abstract mechanism by which senders inform + the network about the congestion recently encountered by packets in + the same flow. Today, network elements at any layer may signal + congestion to the receiver by dropping packets or by Explicit + Congestion Notification (ECN) markings, and the receiver passes this + information back to the sender in transport-layer feedback. The + mechanism described here enables the sender to also relay this + congestion information back into the network in-band at the IP layer, + such that the total amount of congestion from all elements on the + path is revealed to all IP elements along the path, where it could, + for example, be used to provide input to traffic management. This + mechanism is called Congestion Exposure, or ConEx. The companion + document, "Congestion Exposure (ConEx) Concepts and Use Cases" + (RFC 6789), provides the entry point to the set of ConEx + documentation. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7713. + + + + + + + + +Mathis & Briscoe Informational [Page 1] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + +Copyright Notice + + Copyright (c) 2015 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Requirements for the ConEx Abstract Mechanism . . . . . . . . 7 + 3.1. Requirements for ConEx Signals . . . . . . . . . . . . . 7 + 3.2. Constraints on the Audit Function . . . . . . . . . . . . 8 + 3.3. Requirements for Non-abstract ConEx Specifications . . . 9 + 4. Encoding Congestion Exposure . . . . . . . . . . . . . . . . 12 + 4.1. Naive Encoding . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. Null Encoding . . . . . . . . . . . . . . . . . . . . . . 13 + 4.3. ECN-Based Encoding . . . . . . . . . . . . . . . . . . . 13 + 4.4. Independent Bits . . . . . . . . . . . . . . . . . . . . 14 + 4.5. Codepoint Encoding . . . . . . . . . . . . . . . . . . . 14 + 4.6. Units Implied by an Encoding . . . . . . . . . . . . . . 15 + 5. Congestion Exposure Components . . . . . . . . . . . . . . . 16 + 5.1. Network Devices (Not Modified) . . . . . . . . . . . . . 16 + 5.2. Modified Senders . . . . . . . . . . . . . . . . . . . . 16 + 5.3. Receivers (Optionally Modified) . . . . . . . . . . . . . 17 + 5.4. Policy Devices . . . . . . . . . . . . . . . . . . . . . 17 + 5.4.1. Congestion Monitoring Devices . . . . . . . . . . . . 18 + 5.4.2. Rest-of-Path Congestion Monitoring . . . . . . . . . 18 + 5.4.3. Congestion Policers . . . . . . . . . . . . . . . . . 18 + 5.5. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6. Support for Incremental Deployment . . . . . . . . . . . . . 23 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 + 8.2. Informative References . . . . . . . . . . . . . . . . . 27 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 + + + + +Mathis & Briscoe Informational [Page 2] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + +1. Introduction + + This document describes an abstract mechanism by which, to a first + approximation, senders inform the network about the congestion + encountered by packets earlier in the same flow. It is not a + complete protocol specification because it is known that designing an + encoding (e.g., packet formats, codepoint allocations, etc.) is + likely to entail compromises that preclude some uses of the protocol. + The goal of this document is to provide a framework for developing + and testing algorithms to evaluate the benefits of the ConEx protocol + and to evaluate the consequences of the compromises in various + different encoding designs. This document lays out requirements for + concrete protocol specifications. + + A companion document [RFC6789] provides the entry point to the set of + ConEx documentation. It outlines concepts that are prerequisites to + understanding why ConEx is useful, and it outlines various ways that + ConEx might be used. + +2. Overview + + As typical end-to-end transport protocols continually seek out more + network capacity, network elements signal whenever congestion + results, and the transports are responsible for controlling this + network congestion [RFC5681]. The more a transport tries to use + capacity that others want to use, the more congestion signals will be + attributable to that transport. Likewise, the more transport + sessions sustained by a user and the longer the user sustains them, + the more congestion signals will be attributable to that user. The + goal of ConEx is to ensure that the resulting congestion signals are + sufficiently visible and robust, because they are an ideal metric for + networks to use as the basis of traffic management or other related + functions. + + Networks indicate congestion by three possible signals: packet loss, + ECN marking, or queueing delay. ECN marking and some packet loss may + be the outcome of Active Queue Management (AQM), which the network + uses to warn senders to reduce their rates. Packet loss is also the + natural consequence of complete exhaustion of a buffer or other + network resource. Some experimental transport protocols and TCP + variants infer impending congestion from increasing queuing delay. + However, delay is too amorphous to use as a congestion metric. In + this and other ConEx documents, the term 'congestion signals' is + generally used solely for ECN markings and packet losses because they + are unambiguous signals of congestion. + + + + + + +Mathis & Briscoe Informational [Page 3] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + In both cases, the congestion signals follow the route indicated 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 + the sender makes some congestion control adjustment. + + This document extends the capabilities of the Internet protocol suite + with the addition of a new Congestion Exposure signal. To a first + approximation, this signal (also shown in Figure 1) relays the + congestion information from the transport sender back through the + internetwork layer where it is visible to any interested + internetwork-layer devices along the forward path. This document + frames the engineering problem of designing the ConEx Signal. The + requirements are described in Section 3 and some example encodings + are presented in Section 4. Section 5 describes all of the protocol + components. + + This new signal is expressly designed to support a variety of new + policy mechanisms that might be used to instrument, monitor, or + manage traffic. The policy devices are not shown in Figure 1 but + might 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 + + + + + +Mathis & Briscoe Informational [Page 4] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + Since the policy devices can affect how traffic is treated, it is + assumed that there is an intrinsic motivation for users, + applications, or operating systems to understate the congestion that + they are causing. Therefore, it is important to be able to audit + ConEx Signals and to be able to apply sufficient sanction to + discourage cheating of congestion policies. The general approach to + auditing is to count signals on the forward path to confirm that + there are never fewer ConEx Signals than congestion signals. Many + ConEx design constraints come from the need to assure that the audit + function is sufficiently robust. The audit function is described in + Section 5.5; however, significant portions of this document (and + prior research [Refb-dis]) are motivated by issues relating to the + audit function and making it robust. + + The congestion and ConEx Signals shown in Figure 1 represent a series + of discrete events: ECN marks or lost packets, carried by the forward + data stream and fed back into the internetwork layer. The policy and + audit functions are most likely to act on the accumulated values of + these signals, for which we use the term "volume". For example, + "traffic volume" is the total number of bytes delivered optionally + over a specified time interval and over some aggregate of traffic + (e.g., 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]. Note + that volume per unit time is average rate. + + A design goal of the ConEx protocol is that the important policy + mechanisms can be implemented per logical link without per-flow state + (see Section 5.4). However, the trade-off is that per-flow state + could be needed to audit ConEx Signals (Section 5.5). This is + justified in that i) auditing at the edges, with a limited number of + flows, enables policy elsewhere, including in the core, without any + per-flow state; ii) auditing can use soft flow state, which does not + require route pinning. + + There is a long standing argument over units of congestion: bytes vs + packets (see [RFC7141] and its references). Section 4.6 explains why + this problem must be addressed carefully. However, this document + does not take a strong position on this issue. Nonetheless, it does + require that the units of congestion must be an explicitly stated + property of any proposed encoding, and the consequences of that + design decision must be evaluated along with other aspects of the + design. + + To be successful, the ConEx protocol needs to have the property that + the relevant stakeholders each have the incentive to unilaterally + start on each stage of partial deployment, which in turn creates + + + + +Mathis & Briscoe Informational [Page 5] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + incentives for further deployment. Furthermore, legacy systems that + will never be upgraded do not become a barrier to deploying ConEx. + Issues relating to partial deployment are described in Section 6. + + Note that ConEx Signals are not intended to be used for fine-grained + congestion control. They are anticipated to be most useful at longer + time scales and/or at coarser granularity than single microflows. + For example, the total congestion caused by a user might serve as an + input to higher-level policy or accountability functions designed to + create incentives for improving user behavior, such as choosing to + send large quantities 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 have the potential to provide a mechanism + to regulate global Internet congestion. From the earliest days of + research on congestion control, there has been a concern that there + is no mechanism to prevent transport designers from incrementally + making protocols more aggressive without bound and spiraling to a + "tragedy of the commons" Internet congestion collapse. The "TCP + friendly" paradigm was created in part to forestall this failure. + However, it no longer commands any authority because it has little to + say about the Internet of today, which has moved beyond the scaling + range of standard TCP. As a consequence, many transports and + applications are opening arbitrarily large numbers of connections or + using arbitrary levels of aggressiveness. ConEx represents a + recognition that the IETF cannot regulate this space directly because + it concerns the behaviour of users and applications, not individual + transport protocols. Instead, the IETF can give network operators + the protocol tools to arbitrate the space themselves with better bulk + traffic management. This, in turn, should create incentives for + users and designers of applications and of 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]. + + ConEx Signals in IP packet headers 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. + + + + +Mathis & Briscoe Informational [Page 6] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + 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 signal advance + notice of the risk of packets contributing to congestion, in + contrast to signalling only 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 + + First-time readers may wish to skim this section, since it is more + understandable having read the entire document. + +3.1. Requirements for ConEx Signals + + Ideally, all the following requirements would be met by a Congestion + Exposure Signal: + + a. The ConEx Signal SHOULD be visible to internetwork-layer devices + along the entire path from the transport sender to the transport + receiver. Equivalently, it SHOULD be present in the IPv4 or IPv6 + header and in the outermost IP header if using IP-in-IP + tunneling. It MAY need to be visible if other encapsulating + headers are used to interconnect networks. The ConEx Signal + SHOULD be immutable once set by the transport sender. A + corollary of these requirements is that 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 additional deployment, both in terms of enabling + ConEx on more devices and adding richer features to existing + devices. Nonetheless, ConEx deployment need never be universal, + + + + +Mathis & Briscoe Informational [Page 7] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + and it is 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 and 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 are likely to require 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. + + It is already known that implementing ConEx Signals is likely to + entail some compromises, and therefore, 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 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 + will know what to design against and implementers of audit devices + will 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. + + + + + + +Mathis & Briscoe Informational [Page 8] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + 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; + + + + +Mathis & Briscoe Informational [Page 9] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + 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. + + + + + + +Mathis & Briscoe Informational [Page 10] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + 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 ways in which it might fail to satisfy these specifications. + + + +Mathis & Briscoe Informational [Page 11] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + +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 for + 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, then this document will still serve as + a reference model. + +4.1. Naive Encoding + + For tutorial purposes, it is helpful to describe a naive encoding of + the ConEx protocol for TCP and similar protocols: 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 this bit and act on it. For example, any device along + the path might limit the rate of all traffic if the rate of marked + (congested) packets exceeds a threshold. + + This simple encoding is sufficient to illustrate many of the benefits + envisioned for ConEx. At first glance, it looks like it might + motivate people to deploy and use it. It is 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 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 is + useful for thought experiments where it can be stipulated that all + participants are honest and it does illustrate some of the incentives + that might be introduced by ConEx. + + + + +Mathis & Briscoe Informational [Page 12] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + +4.2. Null Encoding + + In limited contexts, it is 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 the history to + count duplicate data. + + This could implement many ConEx policies, without any explicit + protocol. It is 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 intending 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 is 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 in order to allow + the Internet community to assess whether different compromises might + be better. + + The problem with re-ECN is that it requires that receivers be ECN + enabled in addition to sender changes. Newer encodings + [CONEX-DESTOPT] overcome this problem by being able to represent loss + and ECN-based congestion separately. + + + + +Mathis & Briscoe Informational [Page 13] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + +4.4. Independent Bits + + This encoding involves flag bits, each of which the sender can set + independently to indicate to the network one of the following four + signals: + + 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 send Not-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 the three 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), which a malicious sender could use to + advantage against naive policy devices that only check each flag + separately. + + As long as the packets in a flow have uniform sizes, it does not + 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} + + + + + + +Mathis & Briscoe Informational [Page 14] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + Each named codepoint has the same meaning as in the encoding using + independent bits in the previous section. The use of 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 is no easy way to know whether + the lost or marked packet signifies bit congestion or packet + congestion. The above ConEx encodings 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 sufficient 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 are counting packets, then we have + three ConEx packets against five lost packets, which is not + sufficient. This problem will not 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 are important. 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. + + + + + +Mathis & Briscoe Informational [Page 15] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + [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 notes that + new techniques will need to be developed to distinguish packet and + bit congestion. + + Given this document describes an abstract ConEx mechanism, it is + 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. + +5.1. Network Devices (Not Modified) + + Congestion signals originate from network devices as they do today. + A congested router, switch, or other network device can discard or + ECN-mark packets when it is 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 is 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 + + + +Mathis & Briscoe Informational [Page 16] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + 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 being 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) + + Any receiving transport may already feedback sufficiently useful + signals to the sender so that it does not need to be altered. + + The native loss or ECN signaling mechanism required for compliance + with existing congestion control standards (e.g., RTCP, Stream + Control Transmission Protocol (SCTP)) will typically be sufficient + for the Sender to generate ConEx Signals. + + 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. The + sender may require more precise feedback from the receiver otherwise + it is at risk of appearing to be understating its ConEx Signals. + + 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]). + +5.4. Policy Devices + + Policy devices are characterised by a need to be configured with a + policy related to the users or neighboring networks being served. In + contrast, auditing devices solely enforce compliance with the ConEx + protocol and do not need to be configured with any client-specific + policy. + + 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. Of course, policy mechanisms may sometimes + choose to focus down on individual flows, but ConEx aims to make + aggregate policy devices feasible. + + + + +Mathis & Briscoe Informational [Page 17] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + +5.4.1. Congestion Monitoring Devices + + Policy devices can typically be decomposed into two functions: + i) monitoring the ConEx Signal to compare it with a policy; then ii) + acting in some way on the result. 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. + + 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. + + Nonetheless, whatever action is invoked, the congestion monitoring + function will always be a necessary part of any policy device. + +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). + + 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). + + 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. + +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. + + + + + + +Mathis & Briscoe Informational [Page 18] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + 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. + + 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. + + 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. + +5.5. Audit + + The most critical aspect of ConEx is the capability to support robust + auditing. It can be assumed that sanctions based on ConEx Signals + will create an intrinsic motivation for users to understate the + congestion that they are causing. So, without strong audit + functions, the ConEx Signal would become understated to the point of + being useless. Therefore, the most important feature of an encoding + design is likely to be the robustness of the auditing it supports. + + The general goal of an auditor is to make sure that any ConEx-enabled + traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit + signals. A concrete definition of the ConEx protocol MUST define + what sufficient means. + + If a ConEx-enabled transport does not carry sufficient ConEx Signals, + then an auditor is likely to apply some sanction to that traffic. + Although sanctions are beyond the scope of this document, an example + sanction might be to throttle the traffic immediately upstream of the + + + + + +Mathis & Briscoe Informational [Page 19] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + auditor to prevent the user from getting any advantage by + understating congestion. Such a throttle would likely include some + combination of delaying or dropping traffic. + + A ConEx auditor might use one of the following techniques: + + Generic loss auditing: For congestion signalled by loss, totally + accurate auditing is not believed to be possible in the general + case because it involves a network node detecting the absence of + some packets when it cannot always necessarily identify + retransmissions or missing packets. The missing packet might + simply be taking a different route, or the IP payload may be + encrypted. + + It is for this reason that it is desirable to motivate the + deploying of ECN, even though ECN is not strictly required for + ConEx. + + ECN auditing: Directly observe and compare the volume of ECN and + ConEx marks. Since the volume of ECN marks rises monotonically + along a path, ECN auditing is most accurate when 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, which appear as duplicate + sequence numbers upstream of the loss and out of order data + downstream of the loss. Since some reordering is present in the + Internet, such a loss estimator would be most accurate near the + sender. Such an audit device should treat non-ECN-capable packets + with encrypted IP payload as Not-ConEx, even if they claim to be + ConEx-capable, unless the operator is also using one of the other + two techniques below that can audit such packets against losses. + + Predominant bottleneck loss auditing: For networks designed so that + losses predominantly occur under the control of one IP-aware + bottleneck node on the path, the auditor could be located at this + bottleneck. It could simply compare ConEx Signals with actual + local packet discards (and ECN marks). This is a good model for + most consumer access networks where audit accuracy could well be + sufficient even if losses occasionally occur elsewhere in the + network. + + Although the auditor at the predominant bottleneck would not be + able to count losses at other nodes, transports would not know + where losses were occurring either. Therefore, a transport would + + + + +Mathis & Briscoe Informational [Page 20] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + not know which losses it could cheat and which ones it couldn't + without getting caught. + + ECN tunnel loss auditing: A network operator can arrange IP-in-IP + tunnels (or IP-in-MPLS, etc.) so that any losses within the + tunnels are deferred until the tunnel egress. Then, the audit + function can be deployed at the egress and be aware of all losses. + This is possible by enabling ECN marking on switches and routers + within a tunnel, irrespective of whether end systems support ECN, + by exploiting a side effect of the way tunnels handle the ECN + field. After encapsulation at the tunnel ingress, the network + should arrange for any non-ECN packets (with '00' in the ECN field + of the outer) to be set to the ECN-capable transport (ECT(0)) + codepoint. Then, if they experience congestion at one of the ECN- + capable switches or routers within the tunnel, some will be ECN- + marked rather than immediately dropped. However, when the tunnel + decapsulator strips the outer from such an ECN-marked packet, if + it finds the inner header has '00' in the ECN field (meaning that + the endpoints do not support ECN), it will automatically drop the + packet, assuming it complies with [RFC6040]. Thus, an audit + function at the decapsulator can know which packets would have + been dropped within 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 use of ECN internally. + + In addition, other audit techniques may be identified in the future. + + [Refb-dis] gives a comprehensive inventory of attacks against audit + proposed by various people. It includes pseudocode for both + deterministic and statistical audit functions designed to thwart + these attacks and analyses the effectiveness of an implementation. + Although 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 + require designing the sanction in concert with the policy functions, + even though they might be implemented in different parts of the + network. However, [Refb-dis] proves audit and policy functions can + be independent as long as audit drops sufficient traffic to + 'normalise' actual congestion signals to be no greater than ConEx + Signals. + + Similarly, the job of incentivising the sending of ConEx-enabled + packets is proper 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 those packets + + + +Mathis & Briscoe Informational [Page 21] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + that have been marked as ConEx-capable. Even if there are Not-ConEx + packets mixed with ConEx packets within a flow, audit will not need + to monitor any Not-ConEx packets. + + Note that in the future it might prove to be desirable to provide + advice on uniformly implementing sanctions, because otherwise + insufficient sanctions could impair the ability to implement policy + elsewhere in the network. + + Some of the audit algorithms require 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 need not overwhelm any one device. The flow + state required for the audit creates itself as it detects new flows. + Therefore, a flow will not fail if it is re-routed away from the + audit box currently holding its flow state, so auditing does not + 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 numerous new short flows. + The audit function can protect itself from this attack by not + allocating new flow state unless a ConEx-Marked packet arrives (e.g., + credit at the start of a flow). Because policy devices rate limit + ConEx-Marked packets, this sets a natural limit to the rate at which + 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 + do not require any per-flow state and can be applied to aggregate + traffic. These might be able to detect the presence of 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, although the implementer needs to counter the + tactic where a source cheats until 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 will be 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. + + + +Mathis & Briscoe Informational [Page 22] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + 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 + + The ConEx abstract protocol described so far is intended to support + incremental deployment in every possible respect. For convenience, + the following list collects together all the features that support + incremental deployment in the concrete ConEx specifications and + points to further information on each: + + Packets: The wire protocol encoding allows each packet to indicate + whether it is using ConEx or not (see Section 4 on + Encoding Congestion Exposure). + + Senders: ConEx requires a modification to the source in order to + send ConEx packet markings (see Section 5.2). Although ConEx + support can be indicated on a packet-by-packet basis, it is likely + that all the packets in a flow will either consistently support + ConEx or consistently not. It is also likely that, if the + implementation of a transport protocol supports ConEx, all the + packets sent from that host using that protocol will be ConEx- + Capable. + + The implementations of some of the transport protocols on a host + might not support ConEx (e.g., the implementation of DNS over UDP + might not support ConEx, while perhaps RTP over UDP and TCP will). + Any non-upgraded transports and non-upgraded hosts will simply + continue to send regular Not-ConEx packets as always. + + A network operator can create incentives for senders to + voluntarily reveal ConEx information (see the item on incremental + deployment by 'Networks' below). + + Receivers: A ConEx source should be able to work with the regular + receiver for the transport in question without requiring any + ConEx-specific modifications. This is true for modern transport + protocols (RTCP, SCTP, etc.) and it is even true for TCP, as long + as the receiver supports SACK, which is widely deployed anyway. + However, it is not true for ECN feedback in TCP. The need for + more precise ECN feedback in TCP is not exclusive to ConEx; for + instance, Data Centre TCP [DCTCP] uses precise feedback to good + effect. Therefore, if a receiver offers precise feedback, + [RFC7560] it will be best if ConEx uses it (see Section 5.3). + + + + + +Mathis & Briscoe Informational [Page 23] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + Alternatively, without sufficiently precise congestion feedback + from the receiver, the source may have to conservatively send + extra ConEx markings in order to avoid understating congestion. + + Proxies: Although it was stated above that ConEx requires a + modification to the source, ConEx Signals could theoretically be + introduced by a proxy for the source as long as it can intercept + feedback from the receiver. Similarly, more precise feedback + could theoretically be provided by a proxy for the receiver rather + than modifying the receiver itself. + + Forwarding: No modification to forwarding or queuing is needed for + ConEx. + + However, once some ConEx is deployed, it is possible that a queue + implementation could optionally take advantage of the ConEx + information in packets. For instance, it has been suggested + [CONEX-DESTOPT] that a queue would be more robust against flooding + if it preferentially discarded Not-ConEx packets then Not-Marked + ConEx packets. + + A ConEx sender re-echoes congestion whether the queues signaling + congestion are ECN enabled or not. Nonetheless, an operator + relying on ConEx Signals is recommended to enable ECN in queues + wherever possible. This is because auditing works best if most + congestion is indicated by ECN rather than loss (see Section 3). + Also, monitoring rest-of-path congestion is not 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 this 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 remain unchanged once set by + the sender, but some encodings may allow changes in transit (e.g., + 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 if a network is removing ConEx Signals (network- + layer encoding requirement H in Section 3.3). + + + + + + +Mathis & Briscoe Informational [Page 24] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + An operator can deploy policy devices (Section 5.4) wherever + traffic enters its network in order to monitor the downstream + congestion that incoming traffic contributes to and control it if + necessary. A network operator can create incentives for the + developers of sending applications and transports to voluntarily + reveal ConEx information. Without ConEx information, a network + 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 solely limit congestion- + causing traffic and otherwise allow complete freedom. This + greater freedom acts as an inducement for the source to volunteer + ConEx information. An operator may also monitor whether a source + transport has sent ConEx packets and treat the same transport with + greater suspicion (e.g., a more stringent rate limit) whenever it + selectively sends packets without ConEx support. See [RFC6789] + for further discussion of deployment incentives for networks and + 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 are not + understating ConEx information. From the viewpoint of one network + operator (say N_a), it only cares that the level of ConEx + signaling is sufficient to cover congestion in its own network. + If traffic continues into a congested downstream network (say + N_b), it is of no concern to the first network (N_a) if the end- + to-end ConEx signaling is insufficient to cover the congestion in + N_b as well. This is N_b's concern, and N_b can both detect such + anomalous traffic and deal with it using ConEx-based audit devices + itself. + +7. Security Considerations + + The only known risk associated with ConEx is that users and + applications are very likely to be motivated to underrepresent the + congestion that they are causing. Significant portions of this + document are about mechanisms to audit the ConEx Signals and create + sufficient sanction to inhibit such 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 have been proposed by various parties. It includes + + + + +Mathis & Briscoe Informational [Page 25] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + pseudocode for both deterministic and statistical audit functions + designed to thwart these attacks and analyses the effectiveness of an + implementation. + + 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. Therefore, + although likely attacks will be similar, there will be more + combinations of attacks to worry about, and 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 and [Refb-dis] should + be referred to for how re-ECN was designed to defend against similar + attacks: + + o Attacks on the audit function (see Section 7.5 of [Refb-dis]): + + Flow ID Whitewashing: Designing the audit function so that a + source cannot gain 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, which would allow one flow + to pull down the average so that the audit function would + discard packets from all flows, not just the offending flow. + + 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. + + o 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, + which seems to represent congestion upstream, but it makes + these packets immune to being further ECN-marked downstream. + + + + + + + +Mathis & Briscoe Informational [Page 26] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + 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. In the interim, [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 + + [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>. + + + + + +Mathis & Briscoe Informational [Page 27] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + [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>. + + + + + +Mathis & Briscoe Informational [Page 28] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + [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>. + + + + + +Mathis & Briscoe Informational [Page 29] + +RFC 7713 ConEx Concepts and Abstract Mechanism December 2015 + + + [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 document was improved by review comments from Toby Moncaster, + Nandita Dukkipati, Mirja Kuehlewind, Caitlin Bestler, Marcelo Bagnulo + Braun, John Leslie, Ingemar Johansson, and David Wagner. + + 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 + + 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/ + + + + + + + + + + + + + + +Mathis & Briscoe Informational [Page 30] + |