< draft-ietf-tsvwg-ecn-l4s-id-06.txt   draft-ietf-tsvwg-ecn-l4s-id-07.txt >
Transport Services (tsv) K. De Schepper Transport Services (tsv) K. De Schepper
Internet-Draft Nokia Bell Labs Internet-Draft Nokia Bell Labs
Intended status: Experimental B. Briscoe, Ed. Intended status: Experimental B. Briscoe, Ed.
Expires: September 12, 2019 CableLabs Expires: January 9, 2020 CableLabs
March 11, 2019 July 8, 2019
Identifying Modified Explicit Congestion Notification (ECN) Semantics Identifying Modified Explicit Congestion Notification (ECN) Semantics
for Ultra-Low Queuing Delay (L4S) for Ultra-Low Queuing Delay (L4S)
draft-ietf-tsvwg-ecn-l4s-id-06 draft-ietf-tsvwg-ecn-l4s-id-07
Abstract Abstract
This specification defines the identifier to be used on IP packets This specification defines the identifier to be used on IP packets
for a new network service called low latency, low loss and scalable for a new network service called low latency, low loss and scalable
throughput (L4S). It is similar to the original (or 'Classic') throughput (L4S). It is similar to the original (or 'Classic')
Explicit Congestion Notification (ECN). 'Classic' ECN marking was Explicit Congestion Notification (ECN). 'Classic' ECN marking was
required to be equivalent to a drop, both when applied in the network required to be equivalent to a drop, both when applied in the network
and when responded to by a transport. Unlike 'Classic' ECN marking, and when responded to by a transport. Unlike 'Classic' ECN marking,
for packets carrying the L4S identifier, the network applies marking for packets carrying the L4S identifier, the network applies marking
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
with Transport-Layer Awareness . . . . . . . . . . . . . 12 with Transport-Layer Awareness . . . . . . . . . . . . . 12
5.4. Interaction of the L4S Identifier with other Identifiers 13 5.4. Interaction of the L4S Identifier with other Identifiers 13
5.4.1. Examples of Other Identifiers Complementing L4S 5.4.1. Examples of Other Identifiers Complementing L4S
Identifiers . . . . . . . . . . . . . . . . . . . . . 13 Identifiers . . . . . . . . . . . . . . . . . . . . . 13
5.4.1.1. Inclusion of Additional Traffic with L4S . . . . 13 5.4.1.1. Inclusion of Additional Traffic with L4S . . . . 13
5.4.1.2. Exclusion of Traffic From L4S Treatment . . . . . 14 5.4.1.2. Exclusion of Traffic From L4S Treatment . . . . . 14
5.4.2. Generalized Combination of L4S and Other Identifiers 15 5.4.2. Generalized Combination of L4S and Other Identifiers 15
6. L4S Experiments . . . . . . . . . . . . . . . . . . . . . . . 16 6. L4S Experiments . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. The 'Prague L4S Requirements' . . . . . . . . . . . 23 Appendix A. The 'Prague L4S Requirements' . . . . . . . . . . . 23
A.1. Requirements for Scalable Transport Protocols . . . . . . 24 A.1. Requirements for Scalable Transport Protocols . . . . . . 24
A.1.1. Use of L4S Packet Identifier . . . . . . . . . . . . 24 A.1.1. Use of L4S Packet Identifier . . . . . . . . . . . . 24
A.1.2. Accurate ECN Feedback . . . . . . . . . . . . . . . . 24 A.1.2. Accurate ECN Feedback . . . . . . . . . . . . . . . . 24
A.1.3. Fall back to Reno-friendly congestion control on A.1.3. Fall back to Reno-friendly congestion control on
packet loss . . . . . . . . . . . . . . . . . . . . . 24 packet loss . . . . . . . . . . . . . . . . . . . . . 25
A.1.4. Fall back to Reno-friendly congestion control on A.1.4. Fall back to Reno-friendly congestion control on
classic ECN bottlenecks . . . . . . . . . . . . . . . 25 classic ECN bottlenecks . . . . . . . . . . . . . . . 25
A.1.5. Reduce RTT dependence . . . . . . . . . . . . . . . . 25 A.1.5. Reduce RTT dependence . . . . . . . . . . . . . . . . 26
A.1.6. Scaling down to fractional congestion windows . . . . 26 A.1.6. Scaling down to fractional congestion windows . . . . 26
A.1.7. Measuring Reordering Tolerance in Time Units . . . . 27 A.1.7. Measuring Reordering Tolerance in Time Units . . . . 27
A.2. Scalable Transport Protocol Optimizations . . . . . . . . 29 A.2. Scalable Transport Protocol Optimizations . . . . . . . . 29
A.2.1. Setting ECT in TCP Control Packets and A.2.1. Setting ECT in TCP Control Packets and
Retransmissions . . . . . . . . . . . . . . . . . . . 29 Retransmissions . . . . . . . . . . . . . . . . . . . 29
A.2.2. Faster than Additive Increase . . . . . . . . . . . . 29 A.2.2. Faster than Additive Increase . . . . . . . . . . . . 30
A.2.3. Faster Convergence at Flow Start . . . . . . . . . . 30 A.2.3. Faster Convergence at Flow Start . . . . . . . . . . 30
Appendix B. Alternative Identifiers . . . . . . . . . . . . . . 30 Appendix B. Alternative Identifiers . . . . . . . . . . . . . . 31
B.1. ECT(1) and CE codepoints . . . . . . . . . . . . . . . . 31 B.1. ECT(1) and CE codepoints . . . . . . . . . . . . . . . . 31
B.2. ECN Plus a Diffserv Codepoint (DSCP) . . . . . . . . . . 33 B.2. ECN Plus a Diffserv Codepoint (DSCP) . . . . . . . . . . 34
B.3. ECN capability alone . . . . . . . . . . . . . . . . . . 35 B.3. ECN capability alone . . . . . . . . . . . . . . . . . . 36
B.4. Protocol ID . . . . . . . . . . . . . . . . . . . . . . . 37 B.4. Protocol ID . . . . . . . . . . . . . . . . . . . . . . . 38
B.5. Source or destination addressing . . . . . . . . . . . . 37 B.5. Source or destination addressing . . . . . . . . . . . . 38
B.6. Summary: Merits of Alternative Identifiers . . . . . . . 37 B.6. Summary: Merits of Alternative Identifiers . . . . . . . 38
Appendix C. Potential Competing Uses for the ECT(1) Codepoint . 38 Appendix C. Potential Competing Uses for the ECT(1) Codepoint . 39
C.1. Integrity of Congestion Feedback . . . . . . . . . . . . 38 C.1. Integrity of Congestion Feedback . . . . . . . . . . . . 39
C.2. Notification of Less Severe Congestion than CE . . . . . 39 C.2. Notification of Less Severe Congestion than CE . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This specification defines the identifier to be used on IP packets This specification defines the identifier to be used on IP packets
for a new network service called low latency, low loss and scalable for a new network service called low latency, low loss and scalable
throughput (L4S). It is similar to the original (or 'Classic') throughput (L4S). It is similar to the original (or 'Classic')
Explicit Congestion Notification (ECN [RFC3168]). 'Classic' ECN Explicit Congestion Notification (ECN [RFC3168]). 'Classic' ECN
marking was required to be equivalent to a drop, both when applied in marking was required to be equivalent to a drop, both when applied in
the network and when responded to by a transport. Unlike 'Classic' the network and when responded to by a transport. Unlike 'Classic'
ECN marking, the network applies L4S marking more immediately and ECN marking, the network applies L4S marking more immediately and
more aggressively than drop, and the transport response to each mark more aggressively than drop, and the transport response to each mark
is reduced and smoothed relative to that for drop. The two changes is reduced and smoothed relative to that for drop. The two changes
counterbalance each other so that the throughput of an L4S flow will counterbalance each other so that the throughput of an L4S flow will
be roughly the same as a 'Classic' flow under the same conditions. be roughly the same as a 'Classic' flow under the same conditions.
Nonetheless, the much more frequent control signals and the finer Nonetheless, the much more frequent control signals and the finer
responses to them result in ultra-low queuing delay without responses to them result in ultra-low queuing delay without
compromising link utilization, and low delay is maintained during compromising link utilization, and low delay is maintained during
high load. high load.
An example of a scalable congestion control that would enable the L4S An example of a scalable congestion control that would enable the L4S
service is Data Centre TCP (DCTCP), which until now has been service is Data Center TCP (DCTCP), which until now has been
applicable solely to controlled environments like data centres applicable solely to controlled environments like data centres
[RFC8257], because it is too aggressive to co-exist with existing [RFC8257], because it is too aggressive to co-exist with existing
TCP. The DualQ Coupled AQM, which is defined in a complementary TCP. The DualQ Coupled AQM, which is defined in a complementary
experimental specification [I-D.ietf-tsvwg-aqm-dualq-coupled], is an experimental specification [I-D.ietf-tsvwg-aqm-dualq-coupled], is an
AQM framework that enables scalable congestion controls like DCTCP to AQM framework that enables scalable congestion controls like DCTCP to
co-exist with existing traffic, each getting roughly the same flow co-exist with existing traffic, each getting roughly the same flow
rate when they compete under similar conditions. Note that a rate when they compete under similar conditions. Note that a
transport such as DCTCP is still not safe to deploy on the Internet transport such as DCTCP is still not safe to deploy on the Internet
unless it satisfies the requirements listed in Section 4. Also note unless it satisfies the requirements listed in Section 4. Also note
that L4S is not only for elastic TCP-like traffic - there are that L4S is not only for elastic TCP-like traffic - there are
skipping to change at page 6, line 24 skipping to change at page 6, line 24
[RFC2119]. In this document, these words will appear with that [RFC2119]. In this document, these words will appear with that
interpretation only when in ALL CAPS. Lower case uses of these words interpretation only when in ALL CAPS. Lower case uses of these words
are not to be interpreted as carrying RFC-2119 significance. are not to be interpreted as carrying RFC-2119 significance.
Classic service: The 'Classic' service is intended for all the Classic service: The 'Classic' service is intended for all the
behaviours that currently co-exist with TCP Reno (e.g. TCP Cubic, behaviours that currently co-exist with TCP Reno (e.g. TCP Cubic,
Compound, SCTP, etc). Compound, SCTP, etc).
Low-Latency, Low-Loss and Scalable (L4S) service: The 'L4S' service Low-Latency, Low-Loss and Scalable (L4S) service: The 'L4S' service
is intended for traffic from scalable congestion control is intended for traffic from scalable congestion control
algorithms such as Data Centre TCP. But it is also more general-- algorithms such as Data Center TCP. But it is also more general--
it allows the set of congestion controls with similar scaling it allows the set of congestion controls with similar scaling
properties to DCTCP to evolve (e.g. Relentless TCP [Mathis09] and properties to DCTCP to evolve (e.g. Relentless TCP [Mathis09] and
the L4S variant of SCREAM for real-time media [RFC8298]. the L4S variant of SCREAM for real-time media [RFC8298].
Both Classic and L4S services can cope with a proportion of Both Classic and L4S services can cope with a proportion of
unresponsive or less-responsive traffic as well, as long as it unresponsive or less-responsive traffic as well, as long as it
does not build a queue (e.g. DNS, VoIP, game sync datagrams, does not build a queue (e.g. DNS, VoIP, game sync datagrams,
etc). etc).
Classic ECN: The original Explicit Congestion Notification (ECN) Classic ECN: The original Explicit Congestion Notification (ECN)
skipping to change at page 9, line 47 skipping to change at page 9, line 47
DCCP: The ACK vector in DCCP [RFC4340] is already sufficient to DCCP: The ACK vector in DCCP [RFC4340] is already sufficient to
report the extent of CE marking as needed by a scalable congestion report the extent of CE marking as needed by a scalable congestion
control. control.
4.3. Prerequisite Congestion Response 4.3. Prerequisite Congestion Response
As a condition for a host to send packets with the L4S identifier As a condition for a host to send packets with the L4S identifier
(ECT(1)), it SHOULD implement a congestion control behaviour that (ECT(1)), it SHOULD implement a congestion control behaviour that
ensures the flow rate is inversely proportional to the proportion of ensures the flow rate is inversely proportional to the proportion of
bytes in packets marked with the CE codepoint. This is termed a bytes in packets marked with the CE codepoint. This is termed a
scalable congestion control, because the number of control signals scalable congestion control, because the average number of control
(ECN marks) per round trip remains roughly constant for any flow signals (ECN marks) per round trip remains roughly constant for any
rate. As with all transport behaviours, a detailed specification flow rate. As with all transport behaviours, a detailed
will need to be defined for each type of transport or application, specification will need to be defined for each type of transport or
including the timescale over which the proportionality is averaged, application, including the timescale over which the proportionality
and control of burstiness. The inverse proportionality requirement is averaged, and control of burstiness. The inverse proportionality
above is worded as a 'SHOULD' rather than a 'MUST' to allow requirement above is worded as a 'SHOULD' rather than a 'MUST' to
reasonable flexibility when defining these specifications. allow reasonable flexibility when defining these specifications.
Data Center TCP (DCTCP [RFC8257]) and the L4S variant of SCReAM Data Center TCP (DCTCP [RFC8257]) and the L4S variant of SCReAM
[RFC8298] are examples of a scalable congestion controls. [RFC8298] are examples of a scalable congestion controls.
Each sender in a session can use a scalable congestion control Each sender in a session can use a scalable congestion control
independently of the congestion control used by the receiver(s) when independently of the congestion control used by the receiver(s) when
they send data. Therefore there might be ECT(1) packets in one they send data. Therefore there might be ECT(1) packets in one
direction and ECT(0) or Not-ECT in the other. direction and ECT(0) or Not-ECT in the other.
In order to coexist safely with other Internet traffic, a scalable In order to coexist safely with other Internet traffic, a scalable
skipping to change at page 11, line 5 skipping to change at page 10, line 50
o A scalable congestion control MUST remain responsive to congestion o A scalable congestion control MUST remain responsive to congestion
when the RTT is significantly smaller than in the current public when the RTT is significantly smaller than in the current public
Internet (see Appendix A.1.6 for rationale). Internet (see Appendix A.1.6 for rationale).
o A scalable congestion control MUST detect loss by counting in o A scalable congestion control MUST detect loss by counting in
time-based units, which is scalable, as opposed to counting in time-based units, which is scalable, as opposed to counting in
units of packets (as in the 3 DupACK rule of traditional TCP), units of packets (as in the 3 DupACK rule of traditional TCP),
which is not scalable (see Appendix A.1.7 for rationale). which is not scalable (see Appendix A.1.7 for rationale).
As well as traffic controlled by a scalable congestion control, a
reasonable level of smooth unresponsive traffic at a low rate
relative to typical broadband capacities is likely to be acceptable
(see "'Safe' Unresponsive Traffic" in Section 5.4.1.1.1).
5. Prerequisite Network Node Behaviour 5. Prerequisite Network Node Behaviour
5.1. Prerequisite Classification and Re-Marking Behaviour 5.1. Prerequisite Classification and Re-Marking Behaviour
A network node that implements the L4S service MUST classify arriving A network node that implements the L4S service MUST classify arriving
ECT(1) packets for L4S treatment and, other than in the exceptional ECT(1) packets for L4S treatment and, other than in the exceptional
case referred to next, it MUST classify arriving CE packets for L4S case referred to next, it MUST classify arriving CE packets for L4S
treatment as well. CE packets might have originated as ECT(1) or treatment as well. CE packets might have originated as ECT(1) or
ECT(0), but the above rule to classify them as if they originated as ECT(0), but the above rule to classify them as if they originated as
ECT(1) is the safe choice (see Appendix B.1 for rationale). The ECT(1) is the safe choice (see Appendix B.1 for rationale). The
exception is where some flow-aware in-network mechanism happens to be exception is where some flow-aware in-network mechanism happens to be
available for distinguishing CE packets that originated as ECT(0), as available for distinguishing CE packets that originated as ECT(0), as
described in Section 5.3, but there is no implication that such a described in Section 5.3, but there is no implication that such a
mechanism is necessary. mechanism is necessary.
An L4S AQM treatment follows similar codepoint transition rules to An L4S AQM treatment follows similar codepoint transition rules to
those in RFC 3168. Specifically, the ECT(1) codepoint MUST NOT be 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 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 any other codepoint. An ECT(1) packet is classified as ECN-capable
and, if congestion increases, an L4S AQM algorithm will mark the ECN and, if congestion increases, an L4S AQM algorithm will increasingly
field as CE for an increasing proportion of packets, otherwise mark the ECN field as CE, otherwise forwarding packets unchanged as
forwarding packets unchanged as ECT(1). Necessary conditions for an ECT(1). Necessary conditions for an L4S marking treatment are
L4S marking treatment are defined in Section 5.2. Under persistent defined in Section 5.2. Under persistent overload an L4S marking
overload an L4S marking treatment SHOULD turn off ECN marking, using treatment SHOULD turn off ECN marking, using drop as a congestion
drop as a congestion signal until the overload episode has subsided, signal until the overload episode has subsided, as recommended for
as recommended for all AQMs in [RFC7567] (Section 4.2.1), which all AQMs in [RFC7567] (Section 4.2.1), which follows the similar
follows the similar advice in RFC 3168 (Section 7). advice in RFC 3168 (Section 7).
For backward compatibility in uncontrolled environments, a network For backward compatibility in uncontrolled environments, a network
node that implements the L4S treatment MUST also implement a classic node that implements the L4S treatment MUST also implement a classic
AQM treatment. It MUST classify arriving ECT(0) and Not-ECT packets AQM treatment. It MUST classify arriving ECT(0) and Not-ECT packets
for treatment by the Classic AQM (see the discussion of the for treatment by the Classic AQM (see the discussion of the
classifier for the dual-queue coupled AQM in classifier for the dual-queue coupled AQM in
[I-D.ietf-tsvwg-aqm-dualq-coupled]). Classic treatment means that [I-D.ietf-tsvwg-aqm-dualq-coupled]). Classic treatment means that
the AQM will mark ECT(0) packets under the same conditions as it the AQM will mark ECT(0) packets under the same conditions as it
would drop Not-ECT packets [RFC3168]. would drop Not-ECT packets [RFC3168].
5.2. The Meaning of L4S CE Relative to Drop 5.2. The Meaning of L4S CE Relative to Drop
The likelihood that an AQM drops a Not-ECT Classic packet (p_C) MUST The likelihood that an AQM drops a Not-ECT Classic packet (p_C) MUST
be roughly proportional to the square of the likelihood that it would be roughly proportional to the square of the likelihood that it would
have marked it if it had been an L4S packet (p_L) {ToDo cross-ref to have marked it if it had been an L4S packet (p_L). That is
new section in l4s-arch that explains the rationale for the square}.
That is
p_C ~= (p_L / k)^2 p_C ~= (p_L / k)^2
The constant of proportionality (k) does not have to be standardised The constant of proportionality (k) does not have to be standardised
for interoperability, but a value of 2 is RECOMMENDED. for interoperability, but a value of 2 is RECOMMENDED.
This formula ensures that Scalable and Classic flows will converge to
roughly equal congestion windows. This is because the congestion
windows of Scalable and Classic congestion controls are inversely
proportional to p_L and sqrt(p_C) respectively. So squaring p_C in
the above formula counterbalances the square root that characterizes
all TCP-friendly flows.
[I-D.ietf-tsvwg-aqm-dualq-coupled] specifies the essential aspects of [I-D.ietf-tsvwg-aqm-dualq-coupled] specifies the essential aspects of
an L4S AQM, as well as recommending other aspects. It gives example an L4S AQM, as well as recommending other aspects. It gives example
implementations in appendices. implementations in appendices.
The term 'likelihood' is used above to allow for marking and dropping The term 'likelihood' is used above to allow for marking and dropping
to be either probabilistic or deterministic. The example AQMs in to be either probabilistic or deterministic. The example AQMs in
[I-D.ietf-tsvwg-aqm-dualq-coupled] drop and mark probabilistically, [I-D.ietf-tsvwg-aqm-dualq-coupled] drop and mark probabilistically,
so the drop probability is arranged to be the square of the marking so the drop probability is arranged to be the square of the marking
probability. Nonetheless, an alternative AQM that dropped and marked probability. Nonetheless, an alternative AQM that dropped and marked
deterministically would be valid, as long as the dropping frequency deterministically would be valid, as long as the dropping frequency
skipping to change at page 13, line 13 skipping to change at page 13, line 17
network). network).
5.4. Interaction of the L4S Identifier with other Identifiers 5.4. Interaction of the L4S Identifier with other Identifiers
5.4.1. Examples of Other Identifiers Complementing L4S Identifiers 5.4.1. Examples of Other Identifiers Complementing L4S Identifiers
5.4.1.1. Inclusion of Additional Traffic with L4S 5.4.1.1. Inclusion of Additional Traffic with L4S
In a typical case for the public Internet a network element that In a typical case for the public Internet a network element that
implements L4S might want to classify some low-rate but unresponsive implements L4S might want to classify some low-rate but unresponsive
traffic (e.g. DNS, voice, game sync packets) into the low latency traffic (e.g. DNS, LDAP, NTP, voice, game sync packets) into the low
queue to mix with L4S traffic. Such non-ECN-based packet types MUST latency queue to mix with L4S traffic. Such non-ECN-based packet
be safe to mix with L4S traffic without harming the low latency types MUST be safe to mix with L4S traffic without harming the low
service, where 'safe' is explained in Section 5.4.1.1.1 below. latency service, where 'safe' is explained in Section 5.4.1.1.1
below.
In this case it would not be appropriate to call the queue an L4S In this case it would not be appropriate to call the queue an L4S
queue, because it is shared by L4S and non-L4S traffic. Instead it queue, because it is shared by L4S and non-L4S traffic. Instead it
will be called the low latency or L queue. The L queue then offers will be called the low latency or L queue. The L queue then offers
two different treatments: two different treatments:
o The L4S treatment, which is a combination of the L4S AQM treatment o The L4S treatment, which is a combination of the L4S AQM treatment
and a priority scheduling treatment; and a priority scheduling treatment;
o The low latency treatment, which is solely the priority scheduling o The low latency treatment, which is solely the priority scheduling
skipping to change at page 13, line 42 skipping to change at page 13, line 47
implements L4S MAY classify additional packets into the L queue if implements L4S MAY classify additional packets into the L queue if
they carry certain non-ECN identifiers. For instance: they carry certain non-ECN identifiers. For instance:
o addresses of specific applications or hosts configured to be safe o addresses of specific applications or hosts configured to be safe
(but for example cannot set the ECN field for some temporary (but for example cannot set the ECN field for some temporary
reason); reason);
o certain protocols that are usually lightweight (e.g. ARP, DNS); o certain protocols that are usually lightweight (e.g. ARP, DNS);
o specific Diffserv codepoints that indicate traffic with limited o specific Diffserv codepoints that indicate traffic with limited
burstiness such as the EF (Expedited Forwarding) and Voice-Admit burstiness such as the EF (Expedited Forwarding [RFC3246]), Voice-
service classes or equivalent local-use DSCPs (see Admit [RFC5865] or proposed NQB (Non-Queue-Building
[I-D.briscoe-tsvwg-l4s-diffserv]). [I-D.white-tsvwg-nqb]) service classes or equivalent local-use
DSCPs (see [I-D.briscoe-tsvwg-l4s-diffserv]).
Of course, a packet that carried both the ECT(1) codepoint and a Of course, a packet that carried both the ECT(1) codepoint and a
relevant non-ECN identifier would also be classified into the L relevant non-ECN identifier would also be classified into the L
queue. queue.
For clarity, non-ECN identifiers, such as the examples itemized For clarity, non-ECN identifiers, such as the examples itemized
above, might be used by some network operators who believe they above, might be used by some network operators who believe they
identify non-L4S traffic that would be safe to mix with L4S traffic. identify non-L4S traffic that would be safe to mix with L4S traffic.
They are not alternative ways for a host to indicate that it is They are not alternative ways for a host to indicate that it is
sending L4S packets. Only the ECT(1) ECN codepoint indicates to a sending L4S packets. Only the ECT(1) ECN codepoint indicates to a
network element that a host is sending L4S packets (and CE indicates network element that a host is sending L4S packets (and CE indicates
that it could be). Specifically ECT(1) indicates that the host that it could be). Specifically ECT(1) indicates that the host
claims its behaviour satisfies the per-requisite transport claims its behaviour satisfies the per-requisite transport
requirements in Section 4. requirements in Section 4.
To include additional traffic with L4S, a network element only reads
identifiers such as those itemized above. It MUST NOT alter these
non-ECN identifiers.
5.4.1.1.1. 'Safe' Unresponsive Traffic 5.4.1.1.1. 'Safe' Unresponsive Traffic
The above section requires unresponsive traffic to be 'safe' to mix The above section requires unresponsive traffic to be 'safe' to mix
with L4S traffic. Ideally this means that the sender never sends any with L4S traffic. Ideally this means that the sender never sends any
sequence of packets at a data rate that exceeds the available sequence of packets at a data rate that exceeds the available
capacity of the bottleneck link. However, typically an unresponsive capacity of the bottleneck link. However, typically an unresponsive
transport does not even know the bottleneck capacity of the path, let transport does not even know the bottleneck capacity of the path, let
alone its available capacity. Nonetheless, an application can be alone its available capacity. Nonetheless, an application can be
considered safe enough if it paces packets out (not necessarily considered safe enough if it paces packets out (not necessarily
completely regularly) such that its maximum instantaneous data rate completely regularly) such that its maximum instantaneous data rate
skipping to change at page 14, line 33 skipping to change at page 14, line 44
rate. rate.
This is a vague but useful definition, because it encompasses many This is a vague but useful definition, because it encompasses many
low latency applications of interest, such as DNS, voice, game sync low latency applications of interest, such as DNS, voice, game sync
packets, RPC, ACKs, keep-alives, etc. packets, RPC, ACKs, keep-alives, etc.
5.4.1.2. Exclusion of Traffic From L4S Treatment 5.4.1.2. Exclusion of Traffic From L4S Treatment
To extend the above example, an operator might want to exclude some To extend the above example, an operator might want to exclude some
traffic from the L4S treatment for policy reason, e.g. security traffic from the L4S treatment for policy reason, e.g. security
(traffic from malicious sources) or commercial (initially the (traffic from malicious sources) or commercial (e.g. initially the
operator may wish to confine the benefits of L4S to business operator may wish to confine the benefits of L4S to business
customers). customers).
In this exclusion case, the operator MUST classify on the relevant In this exclusion case, the operator MUST classify on the relevant
locally-used identifiers (e.g. source addresses) before classifying locally-used identifiers (e.g. source addresses) before classifying
the non-matching traffic on the end-to-end L4S ECN identifier. the non-matching traffic on the end-to-end L4S ECN identifier.
The operator MUST NOT re-mark the end-to-end L4S identifier, because The operator MUST NOT alter the end-to-end L4S ECN identifier,
its decision to exclude certain traffic from L4S treatment is local- because its decision to exclude certain traffic from L4S treatment is
only. The end-to-end L4S identifier then survives for other local-only. The end-to-end L4S identifier then survives for other
operators to use, or indeed, they can apply their own policy, operators to use, or indeed, they can apply their own policy,
independently based on their own choice of locally-used identifiers. independently based on their own choice of locally-used identifiers.
This approach also allows any operator to remove its locally-applied This approach also allows any operator to remove its locally-applied
exclusions in future, e.g. if it wishes to widen the benefit of the exclusions in future, e.g. if it wishes to widen the benefit of the
L4S treatment to all its customers. L4S treatment to all its customers.
5.4.2. Generalized Combination of L4S and Other Identifiers 5.4.2. Generalized Combination of L4S and Other Identifiers
L4S concerns low latency, which it can provide for all traffic L4S concerns low latency, which it can provide for all traffic
without differentiation and without affecting bandwidth allocation. without differentiation and without affecting bandwidth allocation.
skipping to change at page 15, line 51 skipping to change at page 16, line 11
of approach, which can be combined: the operator might split certain of approach, which can be combined: the operator might split certain
Diffserv PHBs between L4S and a corresponding Classic service. Or it Diffserv PHBs between L4S and a corresponding Classic service. Or it
might split the L4S and/or the Classic service into multiple Diffserv might split the L4S and/or the Classic service into multiple Diffserv
PHBs. In any of these cases, a packet would have to be classified on PHBs. In any of these cases, a packet would have to be classified on
its Diffserv and ECN codepoints. its Diffserv and ECN codepoints.
In summary, there are numerous ways in which the L4S ECN identifier In summary, there are numerous ways in which the L4S ECN identifier
(ECT(1) and CE) could be combined with other identifiers to achieve (ECT(1) and CE) could be combined with other identifiers to achieve
particular objectives. The following categorization articulates particular objectives. The following categorization articulates
those that are valid, but it is not necessarily exhaustive. Those those that are valid, but it is not necessarily exhaustive. Those
tagged 'Global-use' could be set by the sending host or a network. tagged 'Recommended-standard-use' could be set by the sending host or
Those tagged 'Local-use' would only be set by a network: a network. Those tagged 'Local-use' would only be set by a network:
1. Identifiers Complementing the L4S Identifier 1. Identifiers Complementing the L4S Identifier
A. Including More Traffic in the L Queue A. Including More Traffic in the L Queue
(Global-use or Local-use) (Recommended-standard-use or Local-use)
B. Excluding Certain Traffic from the L Queue B. Excluding Certain Traffic from the L Queue
(Local-use only) (Local-use only)
2. Identifiers to place L4S classification in a PHB Hierarchy 2. Identifiers to place L4S classification in a PHB Hierarchy
(Global-use or Local-use) (Recommended-standard-use or Local-use)
A. PHBs Before L4S ECN Classification A. PHBs Before L4S ECN Classification
B. PHBs After L4S ECN Classification B. PHBs After L4S ECN Classification
6. L4S Experiments 6. L4S Experiments
[I-D.ietf-tsvwg-aqm-dualq-coupled] sets operational and management [I-D.ietf-tsvwg-aqm-dualq-coupled] sets operational and management
requirements for experiments with DualQ Coupled AQMs. General requirements for experiments with DualQ Coupled AQMs. General
operational and management requirements for experiments with L4S operational and management requirements for experiments with L4S
skipping to change at page 16, line 51 skipping to change at page 17, line 12
The requirement to detect loss in time units prevents the ACK- The requirement to detect loss in time units prevents the ACK-
splitting attacks described in [Savage-TCP]. splitting attacks described in [Savage-TCP].
9. Acknowledgements 9. Acknowledgements
Thanks to Richard Scheffenegger, John Leslie, David Taeht, Jonathan Thanks to Richard Scheffenegger, John Leslie, David Taeht, Jonathan
Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson and Andrew Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson and Andrew
McGregor for the discussions that led to this specification. Ing-jyh McGregor for the discussions that led to this specification. Ing-jyh
(Inton) Tsang was a contributor to the early drafts of this document. (Inton) Tsang was a contributor to the early drafts of this document.
And thanks to Mikael Abrahamsson, Lloyd Wood, Nicolas Kuhn, Greg And thanks to Mikael Abrahamsson, Lloyd Wood, Nicolas Kuhn, Greg
White, David Black and Gorry Fairhurst for providing help and White, Tom Henderson, David Black, Gorry Fairhurst and Brian
reviewing this draft and to Ingemar Johansson for reviewing and Carpenter for providing help and reviewing this draft and to Ingemar
providing substantial text. Appendix A listing the Prague L4S Johansson for reviewing and providing substantial text. Appendix A
Requirements is based on text authored by Marcelo Bagnulo Braun that listing the Prague L4S Requirements is based on text authored by
was originally an appendix to [I-D.ietf-tsvwg-l4s-arch]. That text Marcelo Bagnulo Braun that was originally an appendix to
was in turn based on the collective output of the attendees listed in [I-D.ietf-tsvwg-l4s-arch]. That text was in turn based on the
the minutes of a 'bar BoF' on DCTCP Evolution during IETF-94 collective output of the attendees listed in the minutes of a 'bar
[TCPPrague]. BoF' on DCTCP Evolution during IETF-94 [TCPPrague].
The authors' contributions were part-funded by the European Community The authors' contributions were part-funded by the European Community
under its Seventh Framework Programme through the Reducing Internet under its Seventh Framework Programme through the Reducing Internet
Transport Latency (RITE) project (ICT-317700). Bob Briscoe was also Transport Latency (RITE) project (ICT-317700). Bob Briscoe was also
part-funded by the Research Council of Norway through the TimeIn part-funded by the Research Council of Norway through the TimeIn
project. The views expressed here are solely those of the authors. project. The views expressed here are solely those of the authors.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 18, line 24 skipping to change at page 18, line 36
November 2018. November 2018.
[I-D.ietf-avtcore-cc-feedback-message] [I-D.ietf-avtcore-cc-feedback-message]
Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
Control Protocol (RTCP) Feedback for Congestion Control", Control Protocol (RTCP) Feedback for Congestion Control",
draft-ietf-avtcore-cc-feedback-message-03 (work in draft-ietf-avtcore-cc-feedback-message-03 (work in
progress), December 2018. progress), December 2018.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-18 (work and Secure Transport", draft-ietf-quic-transport-20 (work
in progress), January 2019. in progress), April 2019.
[I-D.ietf-tcpm-accurate-ecn] [I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-
ecn-08 (work in progress), March 2019. ecn-08 (work in progress), March 2019.
[I-D.ietf-tcpm-generalized-ecn] [I-D.ietf-tcpm-generalized-ecn]
Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
Congestion Notification (ECN) to TCP Control Packets", Congestion Notification (ECN) to TCP Control Packets",
draft-ietf-tcpm-generalized-ecn-03 (work in progress), draft-ietf-tcpm-generalized-ecn-03 (work in progress),
October 2018. October 2018.
[I-D.ietf-tcpm-rack] [I-D.ietf-tcpm-rack]
Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK: Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK:
a time-based fast loss detection algorithm for TCP", a time-based fast loss detection algorithm for TCP",
draft-ietf-tcpm-rack-04 (work in progress), July 2018. draft-ietf-tcpm-rack-05 (work in progress), April 2019.
[I-D.ietf-tsvwg-aqm-dualq-coupled] [I-D.ietf-tsvwg-aqm-dualq-coupled]
Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang, Schepper, K., Briscoe, B., and G. White, "DualQ Coupled
"DualQ Coupled AQMs for Low Latency, Low Loss and Scalable AQMs for Low Latency, Low Loss and Scalable Throughput
Throughput (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-08 (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-09 (work in
(work in progress), November 2018. progress), July 2019.
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler, Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to "Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-11 (work in progress), November 2018. encap-guidelines-13 (work in progress), May 2019.
[I-D.ietf-tsvwg-l4s-arch] [I-D.ietf-tsvwg-l4s-arch]
Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency,
Low Loss, Scalable Throughput (L4S) Internet Service: Low Loss, Scalable Throughput (L4S) Internet Service:
Architecture", draft-ietf-tsvwg-l4s-arch-03 (work in Architecture", draft-ietf-tsvwg-l4s-arch-03 (work in
progress), October 2018. progress), October 2018.
[I-D.sridharan-tcpm-ctcp] [I-D.sridharan-tcpm-ctcp]
Sridharan, M., Tan, K., Bansal, D., and D. Thaler, Sridharan, M., Tan, K., Bansal, D., and D. Thaler,
"Compound TCP: A New TCP Congestion Control for High-Speed "Compound TCP: A New TCP Congestion Control for High-Speed
and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02
(work in progress), November 2008. (work in progress), November 2008.
[I-D.stewart-tsvwg-sctpecn] [I-D.stewart-tsvwg-sctpecn]
Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream
Control Transmission Protocol (SCTP)", draft-stewart- Control Transmission Protocol (SCTP)", draft-stewart-
tsvwg-sctpecn-05 (work in progress), January 2014. tsvwg-sctpecn-05 (work in progress), January 2014.
[I-D.white-tsvwg-nqb]
White, G. and T. Fossati, "Identifying and Handling Non
Queue Building Flows in a Bottleneck Link", draft-white-
tsvwg-nqb-02 (work in progress), June 2019.
[Mathis09] [Mathis09]
Mathis, M., "Relentless Congestion Control", PFLDNeT'09 , Mathis, M., "Relentless Congestion Control", PFLDNeT'09 ,
May 2009, <http://www.hpcc.jp/pfldnet2009/ May 2009, <http://www.hpcc.jp/pfldnet2009/
Program_files/1569198525.pdf>. Program_files/1569198525.pdf>.
[Paced-Chirping] [Paced-Chirping]
Misund, J., "Rapid Acceleration in TCP Prague", Masters Misund, J., "Rapid Acceleration in TCP Prague", Masters
Thesis , May 2018, Thesis , May 2018,
<https://riteproject.files.wordpress.com/2018/07/ <https://riteproject.files.wordpress.com/2018/07/
misundjoakimmastersthesissubmitted180515.pdf>. misundjoakimmastersthesissubmitted180515.pdf>.
skipping to change at page 21, line 26 skipping to change at page 21, line 41
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009, RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>. <https://www.rfc-editor.org/info/rfc5706>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010,
<https://www.rfc-editor.org/info/rfc5865>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. [RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B.
Briscoe, "Open Research Issues in Internet Congestion Briscoe, "Open Research Issues in Internet Congestion
Control", RFC 6077, DOI 10.17487/RFC6077, February 2011, Control", RFC 6077, DOI 10.17487/RFC6077, February 2011,
<https://www.rfc-editor.org/info/rfc6077>. <https://www.rfc-editor.org/info/rfc6077>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
skipping to change at page 27, line 48 skipping to change at page 28, line 17
deliver packets strictly in order. Such links typically give deliver packets strictly in order. Such links typically give
arriving packets a link-level sequence number and introduce delay arriving packets a link-level sequence number and introduce delay
while buffering packets at the receiving end until they can be while buffering packets at the receiving end until they can be
delivered in the same order. For radio links, this delay usually delivered in the same order. For radio links, this delay usually
includes the time allowed for link-layer retransmissions. includes the time allowed for link-layer retransmissions.
Note, however, that a link technology will only be able to relax its Note, however, that a link technology will only be able to relax its
ordering requirement if it is certain that it will not degrade the ordering requirement if it is certain that it will not degrade the
transport /most/ sensitive to reordering that might use the link. transport /most/ sensitive to reordering that might use the link.
Also note that in some controlled environments no reordering is Also note that in some controlled environments no reordering is
tolerated by some transports (e.g. RoCEv2 ussed for RDMA), therefore tolerated by some transports (e.g. RoCEv2 used for RDMA), therefore
a switch to time-based units could not be exploited to relax a switch to time-based units could not be exploited to relax
reordering. reordering.
For receivers that need their packets in order, it would seem that For receivers that need their packets in order, it would seem that
relaxing network ordering would simply shift this reordering delay relaxing network ordering would simply shift this reordering delay
from the network to the receiver. However, that is not true in the from the network to the receiver. However, that is not true in the
general case because links generally do not recognize transport layer general case because links generally do not recognize transport layer
flows and often cannot even see application layer streams within the flows and often cannot even see application layer streams within the
flows (as in SCTP, HTTP/2 or QUIC). So a link will often be holding flows (as in SCTP, HTTP/2 or QUIC). So a link will often be holding
back packets from one flow or stream while waiting for those from back packets from one flow or stream while waiting for those from
skipping to change at page 32, line 5 skipping to change at page 32, line 22
ECT(0) codepoint was 'wasted' purely to distinguish one form of ECT(0) codepoint was 'wasted' purely to distinguish one form of
ECN from its successor; ECN from its successor;
ECN hard in some lower layers: It is not always possible to support 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 ECN in an AQM acting in a buffer below the IP layer
[I-D.ietf-tsvwg-ecn-encap-guidelines]. In such cases, the L4S [I-D.ietf-tsvwg-ecn-encap-guidelines]. In such cases, the L4S
service would have to drop rather than mark frames even though service would have to drop rather than mark frames even though
they might contain an ECN-capable packet. However, such cases they might contain an ECN-capable packet. However, such cases
would be unusual. would be unusual.
Risk of reordering classic CE packets: Having to classify all CE Risk of reordering classic CE packets: Classifying all CE packets
packets as L4S risks some classic CE packets being wrongly into the L4S queue risks any CE packets that were originally
classified as L4S and arriving early, which is a form of ECT(0) being incorrectly classified as L4S. If there were delay
reordering. Reordering can cause the TCP sender to retransmit in the Classic queue, these incorrectly classified CE packets
spuriously. However, the risk of spurious retransmissions would would arrive early, which is a form of reordering. Reordering can
be extremely low, because: cause TCP senders (and senders of similar transports) to
retransmit spuriously. However, the risk of spurious
retransmissions would be extremely low for the following reasons:
1. it is quite unusual to experience more than one bottleneck 1. It is quite unusual to experience queuing at more than one
queue on a path. bottleneck on the same path (the available capacities have to
be identical).
2. It would be even more unusual for the first bottleneck to 2. In only a subset of these unusual cases would the first
support classic ECN marking and for the second to support L4S bottleneck support classic ECN marking while the second
ECN marking supported L4S ECN marking, which would be the only scenario
where some ECT(0) packets could be CE marked by a non-L4S AQM
then the remainder experienced further delay through the
Classic side of a subsequent L4S DualQ AQM.
3. even then, reordering would only occur if there was 3. Even then, when a few packets are delivered early, it takes
simultaneous mixing of classic and L4S traffic, which would be very unusual conditions to cause a spurious retransmission, in
more unlikely in an access link, which is where most contrast to when some packets are delivered late. The first
bottlenecks are located; bottleneck has to apply CE-marks to at least N contiguous
packets and the second bottleneck has to inject an
uninterrupted sequence of at least N of these packets between
two packets earlier in the stream (where N is the reordering
window that the transport protocol allows before it considers
a packet is lost).
4. even then, spurious retransmissions would only occur if a For example consider N=3, and consider the sequence of
contiguous sequence of three or more packets in one classic packets 100, 101, 102, 103,... and imagine that packets
ECN flow were all CE-marked at the first bottleneck; 150,151,152 from later in the flow are injected as follows:
100, 150, 151, 101, 152, 102, 103... If this were late
reordering, even one packet arriving 50 out of sequence
would trigger a spurious retransmission, but there is no
spurious retransmission here, because packet 101 moves the
cumulative ACK counter forward before 3 packets have
arrived out of order. Later, when packets 148, 149, 153...
arrive, even though there is a 3-packet hole, there will be
no problem, because the packets to fill the hole are
already in the receive buffer.
5. even then, a spurious retransmission would only occur if the 4. Even with the current recommended TCP (N=3) spurious
source did not support RACK [I-D.ietf-tcpm-rack], which is retransmissions will be unlikely for all the above reasons.
already widely supported. Otherwise a whole reordering window As RACK [I-D.ietf-tcpm-rack] is becoming widely deployed, it
within one classic ECN flow would have to be marked CE at the tends to adapt its reordering window to a larger value of N,
first bottleneck to cause a spurious retransmission. which will make the chance of a contiguous sequence of N early
arrivals vanishingly small.
It is extremely unlikely that a set of 5 eventualities that are 5. Even a run of 2 CE marks within a classic ECN flow is
each unusual in themselves would all happen simultaneously. But, unlikely, given FQ-CoDel is the only known widely deployed AQM
even if they did, it would only cause spurious retransmission of a that supports classic ECN marking and it takes great care to
packet. separate out flows and to space any markings evenly along each
flow.
It is extremely unlikely that the above set of 5 eventualities
that are each unusual in themselves would all happen
simultaneously. But, even if they did, the consequences would
hardly be dire: the odd spurious fast retransmission. Admittedly
TCP reduces its congestion window when it deems there has been a
loss, but even this can be recovered once the sender detects that
the retransmission was spurious.
Non-L4S service for control packets: The classic ECN RFCs [RFC3168] Non-L4S service for control packets: The classic ECN RFCs [RFC3168]
and [RFC5562] require a sender to clear the ECN field to Not-ECT and [RFC5562] require a sender to clear the ECN field to Not-ECT
for retransmissions and certain control packets specifically pure for retransmissions and certain control packets specifically pure
ACKs, window probes and SYNs. When L4S packets are classified by ACKs, window probes and SYNs. When L4S packets are classified by
the ECN field alone, these control packets would not be classified the ECN field alone, these control packets would not be classified
into an L4S queue, and could therefore be delayed relative to the into an L4S queue, and could therefore be delayed relative to the
other packets in the flow. This would not cause re-ordering other packets in the flow. This would not cause re-ordering
(because retransmissions are already out of order, and the control (because retransmissions are already out of order, and the control
packets carry no data). However, it would make critical control packets carry no data). However, it would make critical control
skipping to change at page 34, line 41 skipping to change at page 35, line 41
likelihood that a DSCP will be bleached or ignored depends on the likelihood that a DSCP will be bleached or ignored depends on the
type of DSCP: type of DSCP:
Local-use DSCP: These tend to be used to implement application- Local-use DSCP: These tend to be used to implement application-
specific network policies, but a bilateral arrangement to specific network policies, but a bilateral arrangement to
remark certain DSCPs is often applied to DSCPs in the local-use remark certain DSCPs is often applied to DSCPs in the local-use
range simply because it is easier not to change all of a range simply because it is easier not to change all of a
network's internal configurations when a new arrangement is network's internal configurations when a new arrangement is
made with a neighbour; made with a neighbour;
Global-use DSCP: These do not tend to be honoured across network Recommended standard DSCP: These do not tend to be honoured
interconnections more than local-use DSCPs. However, if two across network interconnections more than local-use DSCPs.
networks decide to honour certain of each other's DSCPs, the However, if two networks decide to honour certain of each
reconfiguration is a little easier if both of their globally other's DSCPs, the reconfiguration is a little easier if both
recognised services are already represented by the relevant of their globally recognised services are already represented
global-use DSCPs. by the relevant recommended standard DSCPs.
Note that today a global-use DSCP gives little more assurance Note that today a recommended standard DSCP gives little more
of end-to-end service than a local-use DSCP. In future the assurance of end-to-end service than a local-use DSCP. In
global-use range might give more assurance of end-to-end future the range recommended as standard might give more
service than local-use, but it is unlikely that either assurance of end-to-end service than local-use, but it is
assurance will be high, particularly given the hosts are unlikely that either assurance will be high, particularly given
included in the end-to-end path. the hosts are included in the end-to-end path.
Not all tunnels: Diffserv codepoints are often not propagated to the Not all tunnels: Diffserv codepoints are often not propagated to the
outer header when a packet is encapsulated by a tunnel header. outer header when a packet is encapsulated by a tunnel header.
DSCPs are propagated to the outer of uniform mode tunnels, but not DSCPs are propagated to the outer of uniform mode tunnels, but not
pipe mode [RFC2983], and pipe mode is fairly common. pipe mode [RFC2983], and pipe mode is fairly common.
ECN hard in some lower layers:: Because this approach uses both the 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 Diffserv and ECN fields, an AQM wil only work at a lower layer if
both can be supported. If individual network operators wished to both can be supported. If individual network operators wished to
deploy an AQM at a lower layer, they would usually propagate an IP deploy an AQM at a lower layer, they would usually propagate an IP
 End of changes. 43 change blocks. 
112 lines changed or deleted 167 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/