Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay
draft-briscoe-tsvwg-ecn-l4s-id-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Koen De Schepper , Bob Briscoe , Ing Jyh Tsang | ||
| Last updated | 2015-10-19 | ||
| Replaced by | draft-ietf-tsvwg-ecn-l4s-id, draft-ietf-tsvwg-ecn-l4s-id, draft-ietf-tsvwg-ecn-l4s-id, draft-ietf-tsvwg-ecn-l4s-id, RFC 9331 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-briscoe-tsvwg-ecn-l4s-id-00
Transport Services (tsv) K. De Schepper
Internet-Draft Bell Labs
Intended status: Experimental B. Briscoe, Ed.
Expires: April 21, 2016 Simula Research Lab
I. Tsang
Bell Labs
October 19, 2015
Identifying Modified Explicit Congestion Notification (ECN) Semantics
for Ultra-Low Queuing Delay
draft-briscoe-tsvwg-ecn-l4s-id-00
Abstract
This specification defines the identifier to be used on IP packets
for a new network service called low latency, low loss and scalable
throughput (L4S). It is similar to the original (or 'Classic')
Explicit Congestion Notification (ECN). 'Classic' ECN marking was
required to be equivalent to a drop, both when applied in the network
and when responded to by a transport. Unlike 'Classic' ECN marking,
the network applies the L4S identifier more immediately and more
aggressively than drop, and the transport response to each mark is
reduced and smoothed relative to that for drop. The two changes
counterbalance each other so that the bit-rate of an L4S flow will be
roughly the same as a 'Classic' flow under the same conditions.
However, the much more frequent control signals and the finer
responses to them result in ultra-low queuing delay without
compromising link utilization, even during high load. Examples of
new active queue management (AQM) marking algorithms and examples of
new transports (whether TCP-like or real-time) are specified
separately. The new L4S identifier is the key piece that enables
them to interwork and distinguishes them from 'Classic' traffic. It
gives an incremental migration path so that existing 'Classic' TCP
traffic will be no worse off, but it can be prevented from degrading
the ultra-low delay and loss of the new scalable transports.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
De Schepper, et al. Expires April 21, 2016 [Page 1]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016.
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
1.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. L4S Packet Identifier . . . . . . . . . . . . . . . . . . . . 6
2.1. L4S Packet Identification Requirements . . . . . . . . . 6
2.2. L4S Packet Identification . . . . . . . . . . . . . . . . 6
2.3. L4S Packet Identification with Transport-Layer Awareness 7
2.4. The Meaning of CE Relative to Drop . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Alternative Identifiers . . . . . . . . . . . . . . 12
A.1. ECT(1) and CE codepoints . . . . . . . . . . . . . . . . 12
A.2. ECN Plus a Diffserv Codepoint (DSCP) . . . . . . . . . . 14
A.3. ECN capability alone . . . . . . . . . . . . . . . . . . 17
A.4. Protocol ID . . . . . . . . . . . . . . . . . . . . . . . 18
A.5. Source or destination addressing . . . . . . . . . . . . 18
A.6. Summary: Merits of Alternative Identifiers . . . . . . . 18
Appendix B. Potential Competing Uses for the ECT(1) Codepoint . 19
B.1. Integrity of Congestion Feedback . . . . . . . . . . . . 19
De Schepper, et al. Expires April 21, 2016 [Page 2]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
B.2. Notification of Less Severe Congestion than CE . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
This specification defines the identifier to be used on IP packets
for a new network service called low latency, low loss and scalable
throughput (L4S). It is similar to the original (or 'Classic')
Explicit Congestion Notification (ECN). 'Classic' ECN marking was
required to be equivalent to a drop, both when applied in the network
and when responded to by a transport. Unlike 'Classic' ECN marking,
the network applies the L4S identifier more immediately and more
aggressively than drop, and the transport response to each mark is
reduced and smoothed relative to that for drop. The two changes
counterbalance each other so that the bit-rate of an L4S flow will be
roughly the same as a 'Classic' flow under the same conditions.
However, the much more frequent control signals and the finer
responses to them result in ultra-low queuing delay without
compromising link utilization, even during high load.
An example of an active queue management (AQM) marking algorithm that
enables the L4S service is the DualQ Coupled AQM defined in a
complementary specification [I-D.briscoe-aqm-dualq-coupled]. An
example of a scalable transport that would enable the L4S service is
Data Centre TCP (DCTCP), which until now has been applicable solely
to controlled environments like data centres
[I-D.bensley-tcpm-dctcp], because it is too aggressive to co-exist
with existing TCP. However, AQMs like DualQ Coupled enable scalable
transports like DCTCP to co-exist with existing traffic, each getting
roughly the same flow rate when they compete under similar
conditions.
The new L4S identifier is the key piece that enables these two parts
to interwork and distinguishes them from 'Classic' traffic. It gives
an incremental migration path so that existing 'Classic' TCP traffic
will be no worse off, but it can be prevented from degrading the
ultra-low delay and loss of the new scalable transports. The
performance improvement is so great that it is hoped it will motivate
initial deployment of the separate parts of this system.
1.1. Problem
Latency is becoming the critical performance factor for many (most?)
applications on the public Internet, e.g. Web, voice, conversational
video, gaming and finance apps. In the developed world, further
increases in access network bit-rate offer diminishing returns,
whereas latency is still a multi-faceted problem. In the last decade
or so, much has been done to reduce propagation time by placing
De Schepper, et al. Expires April 21, 2016 [Page 3]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
caches or servers closer to users. However, queuing remains a major
component of latency.
The Diffserv architecture provides Expedited Forwarding [RFC3246], so
that low latency traffic can jump the queue of other traffic.
However, on access links dedicated to individual sites (homes, small
enterprises or mobile devices), often all traffic at any one time
will be latency-sensitive. Then Diffserv is of little use. Instead,
we need to remove the causes of any unnecessary delay.
The bufferbloat project has shown that excessively-large buffering
(`bufferbloat') has been introducing significantly more delay than
the underlying propagation time. These delays appear only
intermittently--only when a capacity-seeking (e.g. TCP) flow is long
enough for the queue to fill the buffer, making every packet in other
flows sharing the buffer sit through the queue.
Active queue management (AQM) was originally developed to solve this
problem (and others). Unlike Diffserv, which gives low latency to
some traffic at the expense of others, AQM controls latency for _all_
traffic in a class. In general, AQMs introduce an increasing level
of discard from the buffer the longer the queue persists above a
shallow threshold. This gives sufficient signals to capacity-seeking
(aka. greedy) flows to keep the buffer empty for its intended
purpose: absorbing bursts. However, RED [RFC2309] and other
algorithms from the 1990s were sensitive to their configuration and
hard to set correctly. So, AQM was not widely deployed. More recent
state-of-the-art AQMs, e.g. fq_CoDel [I-D.ietf-aqm-fq-codel],
PIE [I-D.ietf-aqm-pie], Adaptive RED [ARED01], define the threshold
in time not bytes, so it is invariant for different link rates.
Latency is not our only concern: It was known when TCP was first
developed that it would not scale to high bandwidth-delay products.
Given regular broadband bit-rates over WAN distances are
already [RFC3649] beyond the scaling range of `classic' TCP Reno,
`less unscalable' Cubic [I-D.zimmermann-tcpm-cubic] and
Compound [I-D.sridharan-tcpm-ctcp] variants of TCP have been
successfully deployed. However, these are now approaching their
scaling limits. Unfortunately, fully scalable TCPs such as DCTCP
[I-D.bensley-tcpm-dctcp] cause `classic' TCP to starve itself, which
is why they have been confined to private data centres or research
testbeds (until now).
It turns out that a TCP algorithm like DCTCP that solves TCP's
scalability problem also solves the latency problem, because the
finer sawteeth cause very little queuing delay. A supporting paper
[DCttH15] gives the full explanation of why the design solves both
the latency and the scaling problems, both in plain English and in
De Schepper, et al. Expires April 21, 2016 [Page 4]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
more precise mathematical form. THe explanation is summarised
without the maths in [I-D.briscoe-aqm-dualq-coupled].
1.2. 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 [RFC2119]. In this
document, these words will appear with that interpretation only when
in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
Classic service: The `Classic' service is intended for all the
behaviours that currently co-exist with TCP Reno (TCP Cubic,
Compound, SCTP, etc).
Low-Latency, Low-Loss and Scalable (L4S): The `L4S' service is
intended for traffic from scalable TCP algorithms such as Data
Centre TCP. But it is also more general--it will allow a set of
congestion controls with similar scaling properties to DCTCP (e.g.
Relentless [Mathis09]) to evolve.
Both Classic and L4S services can cope with a proportion of
unresponsive or less-responsive traffic as well (e.g. DNS, VoIP,
etc).
Classic ECN: The original Explicit Congestion Notification (ECN)
protocol [RFC3168].
1.3. Scope
.The new L4S identifier defined in this specification is applicable
for IPv4 and IPv6 packets (as for classic ECN [RFC3168]). It is
applicable for the unicast, multicast and anycast forwarding modes.
It is an orthogonal packet classification to Differentiated Services
(Diffserv [RFC2474]), therefore it can be applied to any packet in
any Diffserv traffic class. However, as with classic ECN, any
particular forwarding node might not implement an active queue
management algorithm in all its DIffserv queues.
This document is intended for experimental status, so it does not
update any standards track RFCs. If the experiment is successful and
this document proceeds to the standards track, it would be expected
to update the specification of ECN in IP and in TCP [RFC3168]. For
packets carrying the L4S identifier, it would update both the
network's ECN marking behaviour and the TCP response to ECN feedback,
making them distinct from the behaviours for drop. It would also
update the specification of ECN in RTP over UDP [RFC6679] {ToDo: DCCP
De Schepper, et al. Expires April 21, 2016 [Page 5]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
and SCTP refs}. Finally, it would also obsolete the experimental ECN
nonce [RFC3540].
2. L4S Packet Identifier
2.1. L4S Packet Identification Requirements
Ideally, the identifier for packets using the Low Latency, Low Loss,
Scalable throughput (L4S) service ought to meet the following
requirements:
o it SHOULD survive end-to-end between source and destination
applications: across the boundary between host and network,
between interconnected networks, and through middleboxes;
o it SHOULD be common to IPv4 and IPv6;
o it SHOULD be incrementally deployable;
o it SHOULD enable an AQM to classify packets encapsulated by outer
IP or lower-layer headers;
o it SHOULD consume minimal extra codepoints;
o it SHOULD not lead to some packets of a transport-layer flow being
served by a different queue from others.
It is recognised that the chosen identifier is unlikely to satisfy
all these requirements, particularly given the limited space left in
the IP header. Therefore a compromise will be necessary, which is
why all the requirements are expressed with the word 'SHOULD' not
'MUST'. Appendix A discusses the pros and cons of the compromises
made in various competing identification schemes. The chosen scheme
is defined in Section 2.2 below.
Whether the identifier would be recoverable if the experiment failed
is a factor that could be taken into account. However, this has not
been made a requirement, because that would favour schemes that would
be easier to fail, rather than those more likely to succeed.
2.2. L4S Packet Identification
The L4S treatment is an alternative packet marking treatment
[RFC4774] to the classic ECN treatment [RFC3168]. Like classic ECN,
it identifies the marking treatment that network nodes are expected
to apply to L4S packets, and it identifies packets that are expected
to have been sent from hosts applying a broad type of behaviour,
termed L4S congestion control.
De Schepper, et al. Expires April 21, 2016 [Page 6]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
For a packet to receive L4S treatment as it is forwarded, the sender
MUST set the ECN field in the IP header (v4 or v6) to the ECT(1)
codepoint.
A network node that implements the L4S service MUST classify arriving
ECT(1) packets for L4S treatment and it SHOULD classify arriving CE
packets for L4S treatment as well. Section 2.3 describes an
exception to this latter rule.
The L4S AQM treatment follows similar codepoint transition rules to
those in RFC 3168. Specifically, the ECT(1) codepoint MUST NOT be
changed to any other codepoint than CE, and CE MUST NOT be changed to
any other codepoint. An ECT(1) packet is classified as ECN-capable
and, if congestion increases, an L4S AQM algorithm will set the ECN
marking of an increasing proportion of packets to CE, otherwise
forwarding packets unchanged as ECT(1). The L4S marking treatment is
defined in Section 2.4. Under persistent overload conditions, the
AQM will follow RFC 3168 and turn off ECN marking, using drop as a
congestion signal until the overload episode has subsided.
The L4S treatment is the default for ECT(1) packets in all Diffserv
Classes [RFC4774].
For backward compatibility, a network node that implements the L4S
treatment MUST also implement a classic AQM treatment. It MUST
classify arriving ECT(0) and Not-ECT packets for treatment by the
Classic AQM. Classic treatment means that the AQM will mark ECT(0)
packets under the same conditions as it would drop Not-ECT packets
[RFC3168].
2.3. L4S Packet Identification with Transport-Layer Awareness
To implement the L4S treatment, a network node does not need to
identify transport-layer flows. Nonetheless, if a network node is
capable of identifying transport-layer flows, it SHOULD classify CE
packets for classic ECN [RFC3168] treatment if the most recent ECT
packet in the same flow was ECT(0). If a network node does not
identify transport-layer flows, or if the most recent ECT packet was
ECT(1), it MUST classify CE packets for L4S treatment.
Only the most recent ECT packet of a flow is used to classify a CE
packet, because a sender might have to switch from sending ECT(1)
(L4S) packets to sending ECT(0) (Classic) packets, or back again, in
the middle of a transport-layer flow. Such a switch-over is likely
to be very rare, but It could be necessary if the path bottleneck
moves from a network node that supports L4S to one that only supports
Classic ECN. Such a change ought to be detectable from the change in
RTT variation.
De Schepper, et al. Expires April 21, 2016 [Page 7]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
2.4. The Meaning of CE Relative to Drop
The likelihood that an AQM drops a Not-ECT Classic packet MUST be
proportional to the square of the likelihood that it would have
marked it if it had been an L4S packet. The constant of
proportionality does not have to be standardised for
interoperability, but a value of 1 is RECOMMENDED.
[I-D.briscoe-aqm-dualq-coupled].specifies the essential aspects of an
L4S AQM, as well as recommending other aspects. It gives an example
implementation in an appendix.
The term 'likelihood' is used above to allow for marking and dropping
to be either probabilistic or deterministic. This example AQM in
[I-D.briscoe-aqm-dualq-coupled] drops and marks probabilistically, so
the drop probability is arranged to be the square of the marking
probability. Nonetheless, an alternative AQM that dropped and marked
deterministically would be valid, as long as the dropping frequency
was proportional to the square of the marking frequency.
Note that, contrary to RFC 3168, an AQM implementing the L4S and
Classic treatments does not mark an ECT(1) packet under the same
conditions that it would have dropped a Not-ECT packet. However, it
does mark and ECT(0) packet under the same conditions that it would
have dropped a Not-ECT packet.
3. IANA Considerations
This specification contains no IANA considerations.
{ToDo: If this specification becomes and experimental RFC, should
IANA be asked to update <http://www.iana.org/assignments/ipv4-tos-
byte/ipv4-tos-byte.xhtml#ipv4-tos-byte-1> so that the reference for
the specification of ECT(1) points to this document, and CE points to
both RFC3168 and this document? I think not, because this
experimental specification will not update RFC3168, which is
standards track.}
4. Security Considerations
Two approaches to assure the integrity of signals using the new
identifer are introduced in Appendix B.1.
5. Acknowledgements
Thanks to Richard Scheffenegger, John Leslie, David Taeht, Jonathan
Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson and Andrew
McGregor for the discussions that led to this specification.
De Schepper, et al. Expires April 21, 2016 [Page 8]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
The authors' contributions are part-funded by the European Community
under its Seventh Framework Programme through the Reducing Internet
Transport Latency (RITE) project (ICT-317700). The views expressed
here are solely those of the authors.
6. References
6.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>.
[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>.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, DOI 10.17487/RFC4774, November 2006,
<http://www.rfc-editor.org/info/rfc4774>.
[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>.
6.2. Informative References
[ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An
Algorithm for Increasing the Robustness of RED's Active
Queue Management", ACIRI Technical Report , August 2001,
<http://www.icir.org/floyd/red.html>.
[DCttH15] De Schepper, K., Bondarenko, O., Briscoe, B., and I.
Tsang, "`Data Centre to the Home': Ultra-Low Latency for
All", 2015, <http://www.bobbriscoe.net/projects/latency/
dctth_preprint.pdf>.
(Under submission)
[I-D.bensley-tcpm-dctcp]
Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P.,
and G. Judd, "Microsoft's Datacenter TCP (DCTCP): TCP
Congestion Control for Datacenters", draft-bensley-tcpm-
dctcp-05 (work in progress), July 2015.
De Schepper, et al. Expires April 21, 2016 [Page 9]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
[I-D.briscoe-aqm-dualq-coupled]
Schepper, K., Briscoe, B., Bondarenko, O., and i. ing-
jyh.tsang@alcatel-lucent.com, "DualQ Coupled AQM for Low
Latency, Low Loss and Scalable Throughput", draft-briscoe-
aqm-dualq-coupled-00 (work in progress), August 2015.
[I-D.ietf-aqm-fq-codel]
Hoeiland-Joergensen, T., McKenney, P.,
dave.taht@gmail.com, d., Gettys, J., and E. Dumazet,
"FlowQueue-Codel", draft-ietf-aqm-fq-codel-01 (work in
progress), July 2015.
[I-D.ietf-aqm-pie]
Pan, R., Natarajan, P., and F. Baker, "PIE: A Lightweight
Control Scheme To Address the Bufferbloat Problem", draft-
ietf-aqm-pie-02 (work in progress), August 2015.
[I-D.ietf-conex-abstract-mech]
Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism and Requirements", draft-
ietf-conex-abstract-mech-13 (work in progress), October
2014.
[I-D.ietf-tcpm-accecn-reqs]
Kuehlewind, M., Scheffenegger, R., and B. Briscoe,
"Problem Statement and Requirements for a More Accurate
ECN Feedback", draft-ietf-tcpm-accecn-reqs-08 (work in
progress), March 2015.
[I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-04 (work in progress), October 2015.
[I-D.moncaster-tcpm-rcv-cheat]
Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
Allow Senders to Identify Receiver Non-Compliance", draft-
moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.
[I-D.sridharan-tcpm-ctcp]
Sridharan, M., Tan, K., Bansal, D., and D. Thaler,
"Compound TCP: A New TCP Congestion Control for High-Speed
and Long Distance Networks", draft-sridharan-tcpm-ctcp-02
(work in progress), November 2008.
De Schepper, et al. Expires April 21, 2016 [Page 10]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
[I-D.zimmermann-tcpm-cubic]
Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
draft-zimmermann-tcpm-cubic-01 (work in progress), April
2015.
[Mathis09]
Mathis, M., "Relentless Congestion Control", PFLDNeT'09 ,
May 2009, <http://www.hpcc.jp/pfldnet2009/
Program_files/1569198525.pdf>.
[QV] Briscoe, B. and P. Hurtig, "Up to Speed with Queue View",
RITE Technical Report , August 2015, <TBA>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
<http://www.rfc-editor.org/info/rfc2309>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003,
<http://www.rfc-editor.org/info/rfc3540>.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, DOI 10.17487/RFC3649, December 2003,
<http://www.rfc-editor.org/info/rfc3649>.
De Schepper, et al. Expires April 21, 2016 [Page 11]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K.
Ramakrishnan, "Adding Explicit Congestion Notification
(ECN) Capability to TCP's SYN/ACK Packets", RFC 5562,
DOI 10.17487/RFC5562, June 2009,
<http://www.rfc-editor.org/info/rfc5562>.
[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B.
Briscoe, "Open Research Issues in Internet Congestion
Control", RFC 6077, DOI 10.17487/RFC6077, February 2011,
<http://www.rfc-editor.org/info/rfc6077>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012,
<http://www.rfc-editor.org/info/rfc6660>.
[VCP] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman,
"One more bit is enough", Proc. SIGCOMM'05, ACM CCR
35(4)37--48, 2005,
<http://doi.acm.org/10.1145/1080091.1080098>.
Appendix A. Alternative Identifiers
This appendix is informative, not normative. It records the pros and
cons of various alternative ways to identify L4S packets to record
the rationale for the choice of ECT(1) (Appendix A.1) as the L4S
identifier. At the end, Appendix A.6 summarises the distinguishing
features of the leading alternatives,.It is intended to supplement,
not replace the detailed text.
The leading solutions all use the ECN field, sometimes in combination
with the Diffserv field. Both the ECN and Diffserv fields have the
additional advantage that they are no different in either IPv4 or
IPv6. A couple of alternatives that use other fields are mentioned
at the end, but it is quickly explained why they are not serious
contenders.
A.1. ECT(1) and CE codepoints
Definition:
Packets with ECT(1) and conditionally packets with CE would
signify L4S semantics as an alternative to the semantics of
classic ECN [RFC3168], specifically:
* The ECT(1) codepoint would signify that the packet was sent by
an L4S-capable sender. Successful negotiation of accurate ECN
De Schepper, et al. Expires April 21, 2016 [Page 12]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
(AccECN) feedback [I-D.ietf-tcpm-accecn-reqs] is a pre-
requisite for a sender to send L4S packets, therefore ECT(1) in
turn signifies that both endpoints support AccECN;
* Given shortage of codepoints, both L4S and classic ECN sides of
an AQM would have to use the same CE codepoint to indicate that
a packet had experienced congestion. If a packet that had
already been marked CE in an upstream buffer arrived at a
subsequent AQM, this AQM would then have to guess whether to
classify CE packets as L4S or classic ECN. Choosing the L4S
treatment would be a safer choice, because then a few classic
packets might arrive early, rather than a few L4S packets
arriving late;
* Additional information might be available if the classifier
were transport-aware. Then it could classify a CE packet for
classic ECN treatment if the most recent ECT packet in the same
flow had been marked ECT(0). However, the L4S service should
not need tranport-layer awareness;
Cons:
Consumes the last ECN codepoint: The L4S service is intended to
supersede the service provided by classic ECN, therefore using
ECT(1) to identify L4S packets could ultimately mean that the
ECT(0) codepoint was `wasted' purely to distinguish one form of
ECN from its successor;
ECN hard in some lower layers: It is not always possible to support
ECN in an AQM acting in a buffer below the IP layer
[I-D.ietf-tsvwg-ecn-encap-guidelines]. In such cases, the L4S
service would have to drop rather than mark frames even though
they might contain an ECN-capable packet. However, such cases
would be unusual.
Risk of reordering classic CE packets: Having to classify all CE
packets as L4S risks some classic CE packets arriving early, which
is a form of reordering. Reordering can cause the TCP sender to
retransmit spuriously. However, one or two packets delivered
early does not cause any spurious retransmissions because the
subsequent packets continue to move the cumulative acknowledgement
boundary forwards. Anyway, even the risk of reordering would be
low, because: i) it is quite unusual to experience more than one
bottleneck queue on a path; ii) even then, reordering would only
occur if there was simultaneous mixing of classic and L4S traffic,
which would be more unlikely in an access link, which is where
most bottlenecks are located; iii) even then, spurious
retransmissions would only occur if a contiguous sequence of three
De Schepper, et al. Expires April 21, 2016 [Page 13]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
or more classic CE packets from one bottleneck arrived at the
next, which should in itself happen very rarely with a good AQM.
The risk would be completely eliminated in AQMs that were
transport-aware (but they should not need to be);
Non-L4S service for control packets: The classic ECN RFCs [RFC3168]
and [RFC5562] require a sender to clear the ECN field to Not-ECT
for retransmissions and certain control packets specifically pure
ACKs, window probes and SYNs. When L4S packets are classified by
the ECN field alone, these control packets would not be classified
into an L4S queue, and could therefore be delayed relative to the
other packets in the flow. This would not cause re-ordering
(because retransmissions are already out of order, and the control
packets carry no data). However, it would make critical control
packets more vulnerable to loss and delay. {ToDo: Discuss the
likelihood that all these packets might be made ECN-capable in
future.}
Pros:
Should work e2e: The ECN field generally works end-to-end across the
Internet. Unlike the DSCP, the setting of the ECN field is at
least forwarded unchanged by networks that do not support ECN, and
networks rarely clear it to zero;
Should work in tunnels: Unlike Diffserv, ECN is defined to always
work across tunnels. However, tunnels do not always implement ECN
processing as they should do, particularly because IPsec tunnels
were defined differently for a few years.
Could migrate to one codepoint: If all classic ECN senders
eventually evolve to use the L4S service, the ECT(0) codepoint
could be reused for some future purpose, but only once use of
ECT(0) packets had reduced to zero, or near-zero, which might
never happen.
A.2. ECN Plus a Diffserv Codepoint (DSCP)
Definition:
For packets with a defined DSCP, all codepoints of the ECN field
(except Not-ECT) would signify alternative L4S semantics to those
for classic ECN [RFC3168], specifically:
* The L4S DSCP would signifiy that the packet came from an L4S-
capable sender;
De Schepper, et al. Expires April 21, 2016 [Page 14]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
* ECT(0) and ECT(1) would both signify that the packet was
travelling between transport endpoints that were both ECN-
capable and supported accurate ECN feedback
[I-D.ietf-tcpm-accecn-reqs];
* CE would signify that the packet had been marked by an AQM
implementing the L4S service.
Use of a DSCP is the only approach for alternative ECN semantics
given as an example in [RFC4774]. However, it was perhaps considered
more for controlled environments than new end-to-end services;
Cons:
Consumes DSCP pairs: A DSCP is obviously not orthogonal to Diffserv.
Therefore, wherever the L4S service is applied to multiple
Diffserv scheduling behaviours, it would be necessary to replace
each DSCP with a pair of DSCPs.
Uses critical lower-layer header space: The resulting increased
number of DSCPs might be hard to support for some lower layer
technologies, e.g. 802.1p and MPLS both offer only 3-bits for a
maximum of 8 traffic class identifiers. Although L4S should
reduce and possibly remove the need for some DSCPs intended for
differentiated queuing delay, it will not remove the need for
Diffserv entirely, because Diffserv is also used to allocate
bandwidth, e.g. by prioritising some classes of traffic over
others when traffic exceeds available capacity.
Not end-to-end (host-network): Very few networks honour a DSCP set
by a host. Typically a network will zero (bleach) the Diffserv
field from all hosts. Sometimes networks will attempt to identify
applications by some form of packet inspection and, based on
network policy, they will set the DSCP considered appropriate for
the identified application. Network-based application
identification might use some combination of protocol ID, port
numbers(s), application layer protocol headers, IP address(es),
VLAN ID(s) and even packet timing.
Not end-to-end (network-network): Very few networks honour a DSCP
received from a neighbouring network. Typically a network will
zero (bleach) the Diffserv field from all neighbouring networks at
an interconnection point. Sometimes bilateral arrangements are
made between networks, such that the receiving network remarks
some DSCPs to those it uses for roughly equivalent services. The
likelihood that a DSCP will be bleached or ignored depends on the
type of DSCP:
De Schepper, et al. Expires April 21, 2016 [Page 15]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
Local-use DSCP: These tend to be used to implement application-
specific network policies, but a bilateral arrangement to
remark certain DSCPs is often applied to DSCPs in the local-use
range simply because it is easier not to change all of a
network's internal configurations when a new arrangement is
made with a neighbour;
Global-use DSCP: These do not tend to be honoured across network
interconnections more than local-use DSCPs. However, if two
networks decide to honour certain of each other's DSCPs, the
reconfiguration is a little easier if both of their globally
recognised services are already represented by the relevant
global-use DSCPs.
Note that today a global-use DSCP gives little more assurance
of end-to-end service than a local-use DSCP. In future the
global-use range might give more assurance of end-to-end
service than local-use, but it is unlikely that either
assurance will be high, particularly given the hosts are
included in the end-to-end path.
Not all tunnels: Diffserv codepoints are often not propagated to the
outer header when a packet is encapsulated by a tunnel header.
DSCPs are propagated to the outer of uniform mode tunnels, but not
pipe mode [RFC2983], and pipe mode is fairly common.
ECN hard in some lower layers:: Because this approach uses both the
Diffserv and ECN fields, an AQM wil only work at a lower layer if
both can be supported. If individual network operators wished to
deploy an AQM at a lower layer, they would usually propagate an IP
Diffserv codepoint to the lower layer, using for example IEEE
802.1p. However, the ECN capability is harder to propagate down
to lower layers because few lower layers support it.
Pros:
Could migrate to e2e: If all usage of classic ECN migrates to usage
of L4S, the DSCP would become redundant, and the ECN capability
alone could eventually identify L4S packets without the
interconnection problems of Diffserv detailed below, and without
having permanently consumed more than one codepoint in the IP
header. Although the DSCP does not generally function as an end-
to-end identifier (see below), it could be used initially by
individual ISPs to introduce the L4S service for their own locally
generated traffic;
De Schepper, et al. Expires April 21, 2016 [Page 16]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
A.3. ECN capability alone
Definition:
This approach uses ECN capability alone as the L4S identifier. It
is only feasible if classic ECN is not widely deployed. The
specific definition of codepoints would be:
* Any ECN codepoint other than Not-ECT would signify an L4S-
capable sender, which in turn would indicate that both
transports supported accurate ECN feedback
[I-D.ietf-tcpm-accecn-reqs];
* ECN codepoints would not be used for classic ECN, and the
classic network service would only be used for Not-ECT packets.
This approach would only be feasible if
A. it was generally agreed that there was little chance of any
classic ECN deployment in any network;
B. developers of operating systems for user devices would only
enable ECN by default once the TCP stack implemented accurate
ECN [I-D.ietf-tcpm-accecn-reqs] including requesting it by
default;
C. hosts would only negotiate accurate ECN if they supported L4S
behaviour. In other words, developers of client OSs would all
have to agree not to encourage further deployment of classic
ECN.
Cons:
Near-infeasible deployment constraints: The constraints for
deployment above represent a highly unlikely set of circumstances,
but not completely impossible. If, despite the above measures, a
pair of hosts did negotiate to use classic ECN, their packets
would be classified into the same queue as L4S traffic, and if
they had to compete with a long-running L4S flow they would get a
very small capacity share;
ECN hard in some lower layers: See the same issue with "ECT(1) and
CE codepoints" (Appendix A.1);
Non-L4S service for control packets: See the same issue with "ECT(1)
and CE codepoints" (Appendix A.1).
Pros:
De Schepper, et al. Expires April 21, 2016 [Page 17]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
Consumes no additional codepoints: The ECT(1) codepoint and all
spare Diffserv codepoints would remain available for future use;
Should work e2e: As with "ECT(1) and CE codepoints" (Appendix A.1);
Should work in tunnels: As with "ECT(1) and CE codepoints"
(Appendix A.1).
A.4. Protocol ID
It has been suggested that a new ID in the IPv4 Protocol field or the
IPv6 Next Header field could identify L4S packets. However this
approach is ruled out by numerous problems:
o A new protocol ID would need to be paired with the old one for
each transport (TCP, SCTP, UDP, etc.);
o In IPv6, there can be a sequence of Next Header fields, and it
would not be obvious which one would be expected to identify a
network service like L4S;
o A new protocol ID would rarely provide an end-to-end service,
because It is well-known that new protocol IDs are often blocked
by numerous types of middlebox;
o The approach is not a solution for AQMs below the IP layer;
A.5. Source or destination addressing
Locally, a network operator could arrange for L4S service to be
applied based on source or destination addressing, e.g. packets from
its own data centre and/or CDN hosts, packets to its business
customers, etc. It could use addressing at any layer, e.g. IP
addresses, MAC addresses, VLAN IDs, etc. Although addressing might
be a useful tactical approach for a single ISP, it would not be a
feasible approach to identify an end-to-end service like L4S. Even
for a single ISP, it would require packet classifiers in buffers to
be dependent on changing topology and address allocation decisions
elsewhere in the network. Therefore this approach is not a feasible
solution.
A.6. Summary: Merits of Alternative Identifiers
Table 1 provides a very high level summary of the pros and cons
detailed against the schemes described respectively in Appendix A.2,
Appendix A.3 and Appendix A.1, for six issues that set them apart.
De Schepper, et al. Expires April 21, 2016 [Page 18]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
+--------------+--------------------+---------+--------------------+
| Issue | DSCP + ECN | ECN | ECT(1) + CE |
+--------------+--------------------+---------+--------------------+
| | initial eventual | initial | initial eventual |
| | | | |
| end-to-end | N . . . ? . | . . Y | . . Y . . Y |
| tunnels | . O . . O . | . . ? | . . ? . . Y |
| lower layers | N . . . ? . | . O . | . O . . . ? |
| codepoints | N . . . . ? | . . Y | N . . . . ? |
| reordering | . . Y . . Y | . . Y | . O . . . ? |
| ctrl pkts | . . Y . . Y | . O . | . O . . . ? |
| | | | |
| | | Note 1 | |
+--------------+--------------------+---------+--------------------+
Note 1: Only feasible if classic ECN is obsolete.
Table 1: Comparison of the Merits of Three Alternative Identifiers
The schemes are scored based on both their capabilities now
('initial') and in the long term ('eventual'). The 'ECN' scheme
shares the 'eventual' scores of the 'ECT(0) + CE' scheme. The scores
are one of 'N, O, Y', meaning 'Poor', 'Ordinary', 'Good'
respectively. The same scores are aligned vertically to aid the eye.
A score of "?" in one of the positions means that this approach might
optimisitically become this good, given sufficient effort. The table
is not meant to be understandable without referring to the text.
Appendix B. Potential Competing Uses for the ECT(1) Codepoint
The ECT(1) codepoint of the ECN field has already been assigned once
for experimental use [RFC3540]. ECN is probably the only remaining
field in the Internet Protocol that is common to IPv4 and IPv6 and
still has potential to work end-to-end, with tunnels and with lower
layers. Therefore, ECT(1) should not be reassigned to a different
experimental use without carefully assessing competing potential
uses. These fall into the following categories:
B.1. Integrity of Congestion Feedback
Receiving hosts can fool a sender into downloading faster by
suppressing feedback of ECN marks (or loss if retransmissions are not
necessary or available otherwise). [RFC3540] proposes that a TCP
sender could set either ECT(0) or ECT(1) in each packet of a flow and
remember the pattern, termed the ECN nonce. If any packet is lost or
congestion marked, the receiver will miss that bit of the sequence.
An ECN Nonce receiver has to feed back the least significant bit of
De Schepper, et al. Expires April 21, 2016 [Page 19]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
the sum, so it cannot suppress feedback of a loss or mark without a
50-50 chance of guessing the sum incorrectly.
As far as is known, the ECN Nonce has never been deployed, and it was
only implemented for a couple of testbed evaluations. It would be
nearly impossible to deploy now, because any misbehaving receiver can
simply opt-out, which would be unremarkable given all receivers
currently opt-out.
Other ways to protect TCP feedback integrity have since been
developed that do not consume any extra codepoints. For instance:
o the sender can test the integrity of the receiver's feedback by
occasionally setting the IP-ECN field to a value normally only set
by the network. Then it can test whether the receiver's feedback
faithfully reports what it expects [I-D.moncaster-tcpm-rcv-cheat].
This works for loss and it will work for the accurate ECN feedback
[I-D.ietf-tcpm-accecn-reqs] intended for L4S;
o A network can enforce a congestion response to its ECN markings
(or packet losses) by auditing congestion exposure (ConEx)
[I-D.ietf-conex-abstract-mech]. Whether the receiver or a
downstream network is suppressing congestion feedback or the
sender is unresponsive to the feedback, or both, ConEx audit can
neutralise any advantage that any of these three parties would
otherwise gain.
ECN in RTP [RFC6679] is defined so that the receiver can ask the
sender to send all ECT(0); all ECT(1); or both randomly. It
recommends that the receiver asks for ECT(0), which is the default.
The sender can choose to ignore the receiver's request. A rather
complex but optional nonce mechaism was included in early drafts of
RFC 6679, but it was replaced with a statement that a nonce mechanism
is not specified, explaining that misbehaving receivers could opt-out
anyway. RFC 6679 as published gives no rationale for why ECT(1) or
'random' might be needed, but it warns that 'random' would make
header compression highly inefficient. The possibility of using
ECT(1) may have been left in the RFC to allow a nonce mechanism to be
added later.
Therefore, it seems unlikely that anyone has implemented the optional
use of ECT(1) for RTP, it even if they have, it seems even less
likely that any deployment actually uses it. However these
assumptions will need to be verified.
De Schepper, et al. Expires April 21, 2016 [Page 20]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
B.2. Notification of Less Severe Congestion than CE
Various researchers have proposed to use ECT(1) as a less severe
congestion notification than CE, particularly to enable flows to fill
available capacity more quickly after an idle period, when another
flow departs or when a flow starts, e.g. VCP [VCP], Queue View (QV)
[QV] {ToDo: Jonathan Morton's ELR if relevant once the promised
write-up appears}.
Before assigning ECT(1) as an identifer for L4S, we must carefully
consider whether it might be better to hold ECT(1) in reserve for
future standardisation of rapid flow acceleration, which is an
important and enduring problem [RFC6077].
Pre-Congestion Notification (PCN) is another scheme that assigns
alternative semantics to the ECN field. It uses ECT(1) to signify a
less severe level of pre-congestion notification than CE [RFC6660].
However, the ECN field only takes on the PCN semantics if packets
carry a Diffserv codepoint defined to indicate PCN marking within a
controlled environment. PCN is required to be applied solely to the
outer header of a tunnel across the controlled region in order not to
interfere with any end-to-end use of the ECN field. Therefore a PCN
region on the path would not interfere with any of the L4S service
identifiers proposed in Appendix A.
Authors' Addresses
Koen De Schepper
Bell Labs
Antwerp
Belgium
Email: koen.de_schepper@alcatel-lucent.com
URI: https://www.bell-labs.com/usr/koen.de_schepper
Bob Briscoe (editor)
Simula Research Lab
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/
De Schepper, et al. Expires April 21, 2016 [Page 21]
Internet-Draft ECN Semantics for Low Queuing Delay October 2015
Ing-jyh Tsang
Bell Labs
Antwerp
Belgium
Email: ing-jyh.tsang@alcatel-lucent.com
De Schepper, et al. Expires April 21, 2016 [Page 22]