Baseline Encoding and Transport of Pre-Congestion Information

Abstract

The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity.

Measuring the state of ECN readiness in servers, clients,and routers

“…Recent work illustrates how ECN may be leveraged to provide new Internet primitives and semantics. In addition to IETF standards leveraging ECN [10,23], the IETF congestion exposure (conex) group is developing experimental standards that expose the source and location of congestion along a path potentially enabling new economic and billing models [7]. Among service providers, congestion, rather than traffic volume, is a potential alternative basis for interconnection and peering agreements [8].…”

Overview of Pre-Congestion Notification Encoding

“…Special perhop behavior, defined in [RFC5670], applies to PCN-traffic. The baseline encoding described in Section 4.1 is defined in [RFC5696]. The intention was to allow for experimental encodings to build upon this baseline.…”

“…However, following the publication of [RFC6040], the working group decided to change its approach and instead standardize only one encoding (the 3-in-1 encoding [RFC6660] described in Section 4.2). Rather than defining the 3-in-1 encoding as a Standards Track extension to the existing baseline encoding [RFC5696], it was agreed that it is best to define a new Standards Track document that obsoletes [RFC5696].…”

Security Assessment of the Internet Protocol Version 4

“…There is also ongoing work in the research community and the IETF to define alternate semantics for the CU/ECN field of IP TOS octet (see [RFC5559], [RFC5670], and [RFC5696]). The application of these methods must be confined to tightly administered domains, and on exit from such domains, all packets need to be (re-)marked with ECN semantics.…”