draft-ietf-tcpm-generalized-ecn-00.txt   draft-ietf-tcpm-generalized-ecn-01.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Experimental B. Briscoe Obsoletes: 5562 (if approved) B. Briscoe
Expires: March 22, 2018 Simula Research Lab Intended status: Experimental CableLabs
September 18, 2017 Expires: April 1, 2018 September 28, 2017
ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control
Packets Packets
draft-ietf-tcpm-generalized-ecn-00 draft-ietf-tcpm-generalized-ecn-01
Abstract Abstract
This document describes an experimental modification to ECN when used This document describes an experimental modification to ECN when used
with TCP. It allows the use of ECN on the following TCP packets: with TCP. It allows the use of ECN on the following TCP packets:
SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 March 22, 2018. This Internet-Draft will expire on April 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Experiment Goals . . . . . . . . . . . . . . . . . . . . 4 1.2. Experiment Goals . . . . . . . . . . . . . . . . . . . . 4
1.3. Document Structure . . . . . . . . . . . . . . . . . . . 5 1.3. Document Structure . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Network (e.g. Firewall) Behaviour . . . . . . . . . . . . 6 3.1. Network (e.g. Firewall) Behaviour . . . . . . . . . . . . 6
3.2. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . 6 3.2. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . 7
3.2.1. SYN . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. SYN . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. SYN-ACK . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. SYN-ACK . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Pure ACK . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Pure ACK . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. Window Probe . . . . . . . . . . . . . . . . . . . . 13 3.2.4. Window Probe . . . . . . . . . . . . . . . . . . . . 14
3.2.5. FIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.5. FIN . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.6. RST . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.6. RST . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. Retransmissions . . . . . . . . . . . . . . . . . . . 14 3.2.7. Retransmissions . . . . . . . . . . . . . . . . . . . 15
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.8. General Fall-back for any Control Packet or
4.1. The Reliability Argument . . . . . . . . . . . . . . . . 15 Retransmission . . . . . . . . . . . . . . . . . . . 16
4.2. SYNs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Argument 1a: Unrecognized CE on the SYN . . . . . . . 16 4.1. The Reliability Argument . . . . . . . . . . . . . . . . 16
4.2.2. Argument 1b: Unrecognized ECT on the SYN . . . . . . 18 4.2. SYNs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. Argument 2: DoS Attacks . . . . . . . . . . . . . . . 20 4.2.1. Argument 1a: Unrecognized CE on the SYN . . . . . . . 17
4.3. SYN-ACKs . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.2. Argument 1b: Unrecognized ECT on the SYN . . . . . . 19
4.4. Pure ACKs . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.3. Argument 2: DoS Attacks . . . . . . . . . . . . . . . 21
4.4.1. Cwnd Response to CE-Marked Pure ACKs . . . . . . . . 23 4.3. SYN-ACKs . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.2. ACK Rate Response to CE-Marked Pure ACKs . . . . . . 24 4.3.1. Response to Congestion on a SYN-ACK . . . . . . . . . 22
4.4.3. Summary: Enabling ECN on Pure ACKs . . . . . . . . . 25 4.3.2. Fall-Back if ECT SYN-ACK Fails . . . . . . . . . . . 23
4.5. Window Probes . . . . . . . . . . . . . . . . . . . . . . 25 4.4. Pure ACKs . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6. FINs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4.1. Cwnd Response to CE-Marked Pure ACKs . . . . . . . . 25
4.7. RSTs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4.2. ACK Rate Response to CE-Marked Pure ACKs . . . . . . 26
4.8. Retransmitted Packets. . . . . . . . . . . . . . . . . . 27 4.4.3. Summary: Enabling ECN on Pure ACKs . . . . . . . . . 26
5. Interaction with popular variants or derivatives of TCP . . . 28 4.5. Window Probes . . . . . . . . . . . . . . . . . . . . . . 27
5.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.6. FINs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. IW10 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.7. RSTs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.8. Retransmitted Packets. . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 4.9. General Fall-back for any Control Packet . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. Interaction with popular variants or derivatives of TCP . . . 31
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 5.1. IW10 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2. TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 31 5.3. TCP Derivatives . . . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
RFC 3168 [RFC3168] specifies support of Explicit Congestion RFC 3168 [RFC3168] specifies support of Explicit Congestion
Notification (ECN) in IP (v4 and v6). By using the ECN capability, Notification (ECN) in IP (v4 and v6). By using the ECN capability,
switches performing Active Queue Management (AQM) can use ECN marks network elements (e.g. routers, switches) performing Active Queue
instead of packet drops to signal congestion to the endpoints of a Management (AQM) can use ECN marks instead of packet drops to signal
communication. This results in lower packet loss and increased congestion to the endpoints of a communication. This results in
performance. RFC 3168 also specifies support for ECN in TCP, but lower packet loss and increased performance. RFC 3168 also specifies
solely on data packets. For various reasons it precludes the use of support for ECN in TCP, but solely on data packets. For various
ECN on TCP control packets (TCP SYN, TCP SYN-ACK, pure ACKs, Window reasons it precludes the use of ECN on TCP control packets (TCP SYN,
probes) and on retransmitted packets. RFC 3168 is silent about the TCP SYN-ACK, pure ACKs, Window probes) and on retransmitted packets.
use of ECN on RST and FIN packets. RFC 5562 [RFC5562] is an RFC 3168 is silent about the use of ECN on RST and FIN packets. RFC
experimental modification to ECN that enables ECN support for TCP 5562 [RFC5562] is an experimental modification to ECN that enables
SYN-ACK packets. ECN support for TCP SYN-ACK packets.
This document defines an experimental modification to ECN [RFC3168] This document defines an experimental modification to ECN [RFC3168]
that enables ECN support on all the aforementioned types of TCP that shall be called ECN++. It enables ECN support on all the
packet. [I-D.ietf-tsvwg-ecn-experimentation] is a standards track aforementioned types of TCP packet.
procedural device that relaxes standards track requirements in RFC
3168 that would otherwise preclude these experimental modifications.
The present document also considers the implications for common ECN++ is a sender-side change. It works whether the two ends of the
derivatives and variants of TCP, such as SCTP [RFC4960], if the TCP connection use classic ECN feedback [RFC3168] or experimental
experiment is successful. One particular variant of TCP adds Accurate ECN feedback (AccECN [I-D.ietf-tcpm-accurate-ecn]).
accurate ECN feedback (AccECN [I-D.ietf-tcpm-accurate-ecn]), without Nonetheless, if the client does not implement AccECN, it cannot use
which ECN support cannot be added to SYNs. Nonetheless, ECN support ECN++ on the one packet that offers most benefit from it - the
can be added to all the other types of TCP packet whether or not initial SYN. Therefore, implementers of ECN++ are RECOMMENDED to
AccECN is also supported. also implement AccECN.
ECN++ is designed for compatibility with a number of latency
improvements to TCP such as TCP Fast Open (TFO [RFC7413]), initial
window of 10 SMSS (IW10 [RFC6928]) and Low latency Low Loss Scalable
Transport (L4S [I-D.ietf-tsvwg-l4s-arch]), but they can all be
implemented and deployed independently.
[I-D.ietf-tsvwg-ecn-experimentation] is a standards track procedural
device that relaxes requirements in RFC 3168 and other standards
track RFCs that would otherwise preclude the experimental
modifications needed for ECN++ and other ECN experiments.
1.1. Motivation 1.1. Motivation
The absence of ECN support on TCP control packets and retransmissions The absence of ECN support on TCP control packets and retransmissions
has a potential harmful effect. In any ECN deployment, non-ECN- has a potential harmful effect. In any ECN deployment, non-ECN-
capable packets suffer a penalty when they traverse a congested capable packets suffer a penalty when they traverse a congested
bottleneck. For instance, with a drop probability of 1%, 1% of bottleneck. For instance, with a drop probability of 1%, 1% of
connection attempts suffer a timeout of about 1 second before the SYN connection attempts suffer a timeout of about 1 second before the SYN
is retransmitted, which is highly detrimental to the performance of is retransmitted, which is highly detrimental to the performance of
short flows. TCP control packets, such as TCP SYNs and pure ACKs, short flows. TCP control packets, particularly TCP SYNs and SYN-
are important for performance, so dropping them is best avoided. ACKs, are important for performance, so dropping them is best
avoided.
Non-ECN control packets particularly harm performance in environments Non-ECN control packets particularly harm performance in environments
where the ECN marking level is high. For example, [judd-nsdi] shows where the ECN marking level is high. For example, [judd-nsdi] shows
that in a data centre (DC) environment where ECN is used (in that in a controlled private data centre (DC) environment where ECN
conjunction with DCTCP), the probability of being able to establish a is used (in conjunction with DCTCP [I-D.ietf-tcpm-dctcp]), the
new connection using a non-ECN SYN packet drops to close to zero even probability of being able to establish a new connection using a non-
when there are only 16 ongoing TCP flows transmitting at full speed. ECN SYN packet drops to close to zero even when there are only 16
In this data centre context, the issue is that DCTCP's aggressive ongoing TCP flows transmitting at full speed. The issue is that
response to packet marking leads to a high marking probability for DCTCP exhibits a much more aggressive response to packet marking
ECN-capable packets, and in turn a high drop probability for non-ECN (which is why it is only applicable in controlled environments).
packets. Therefore non-ECN SYNs are dropped aggressively, rendering This leads to a high marking probability for ECN-capable packets, and
it nearly impossible to establish a new connection in the presence of in turn a high drop probability for non-ECN packets. Therefore non-
even mild traffic load. ECN SYNs are dropped aggressively, rendering it nearly impossible to
establish a new connection in the presence of even mild traffic load.
Finally, there are ongoing experimental efforts to promote the Finally, there are ongoing experimental efforts to promote the
adoption of a slightly modified variant of DCTCP (and similar adoption of a slightly modified variant of DCTCP (and similar
congestion controls) over the Internet to achieve low latency, low congestion controls) over the Internet to achieve low latency, low
loss and scalable throughput (L4S) for all communications loss and scalable throughput (L4S) for all communications
[I-D.briscoe-tsvwg-l4s-arch]. In such an approach, L4S packets [I-D.ietf-tsvwg-l4s-arch]. In such an approach, L4S packets identify
identify themselves using an ECN codepoint. With L4S and potentially themselves using an ECN codepoint [I-D.ietf-tsvwg-ecn-l4s-id]. With
other similar cases, preventing TCP control packets from obtaining L4S and potentially other similar cases, preventing TCP control
the benefits of ECN would not only expose them to the prevailing packets from obtaining the benefits of ECN would not only expose them
level of congestion loss, but it would also classify control packet to the prevailing level of congestion loss, but it would also
into a different queue with different network treatment, which may classify control packets into a different queue with different
also lead to reordering, further degrading TCP performance. network treatment, which may also lead to reordering, further
degrading TCP performance.
1.2. Experiment Goals 1.2. Experiment Goals
The goal of the experimental modifications defined in this document The goal of the experimental modifications defined in this document
is to allow the use of ECN on all TCP packets. Experiments are is to allow the use of ECN on all TCP packets. Experiments are
expected in the public Internet as well as in controlled environments expected in the public Internet as well as in controlled environments
to understand the following issues: to understand the following issues:
o How SYNs, Window probes, pure ACKs, FINs, RSTs and retransmissions o How SYNs, Window probes, pure ACKs, FINs, RSTs and retransmissions
that carry the ECT(0), ECT(1) or CE codepoints are processed by that carry the ECT(0), ECT(1) or CE codepoints are processed by
skipping to change at page 6, line 9 skipping to change at page 6, line 19
Retransmission: A TCP segment that has been retransmitted by the TCP Retransmission: A TCP segment that has been retransmitted by the TCP
sender. sender.
ECT: ECN-Capable Transport. One of the two codepoints ECT(0) or ECT: ECN-Capable Transport. One of the two codepoints ECT(0) or
ECT(1) in the ECN field [RFC3168] of the IP header (v4 or v6). An ECT(1) in the ECN field [RFC3168] of the IP header (v4 or v6). An
ECN-capable sender sets one of these to indicate that both transport ECN-capable sender sets one of these to indicate that both transport
end-points support ECN. When this specification says the sender sets end-points support ECN. When this specification says the sender sets
an ECT codepoint, by default it means ECT(0). Optionally, it could an ECT codepoint, by default it means ECT(0). Optionally, it could
mean ECT(1), which is in the process of being redefined for use by mean ECT(1), which is in the process of being redefined for use by
L4S experiments [I-D.ietf-tsvwg-ecn-experimentation] L4S experiments [I-D.ietf-tsvwg-ecn-experimentation]
[I-D.briscoe-tsvwg-ecn-l4s-id]. [I-D.ietf-tsvwg-ecn-l4s-id].
Not-ECT: The ECN codepoint set by senders that indicates that the Not-ECT: The ECN codepoint set by senders that indicates that the
transport is not ECN-capable. transport is not ECN-capable.
CE: Congestion Experienced. The ECN codepoint that an intermediate CE: Congestion Experienced. The ECN codepoint that an intermediate
node sets to indicate congestion [RFC3168]. A node sets an node sets to indicate congestion [RFC3168]. A node sets an
increasing proportion of ECT packets to CE as the level of congestion increasing proportion of ECT packets to CE as the level of congestion
increases. increases.
3. Specification 3. Specification
skipping to change at page 6, line 47 skipping to change at page 7, line 10
to non-ECN. However, this loses the benefit of ECN on control to non-ECN. However, this loses the benefit of ECN on control
packets. So operators are RECOMMENDED to alter their firewall rules packets. So operators are RECOMMENDED to alter their firewall rules
to comply with the requirement referred to above (section 4.3 of to comply with the requirement referred to above (section 4.3 of
[I-D.ietf-tsvwg-ecn-experimentation]). [I-D.ietf-tsvwg-ecn-experimentation]).
3.2. Endpoint Behaviour 3.2. Endpoint Behaviour
The changes to the specification of TCP over ECN [RFC3168] defined The changes to the specification of TCP over ECN [RFC3168] defined
here solely alter the behaviour of the sending host for each half- here solely alter the behaviour of the sending host for each half-
connection. All changes can be deployed at each end-point connection. All changes can be deployed at each end-point
independently of others. independently of others and independent of any network behaviour.
The feedback behaviour at the receiver depends on whether classic ECN The feedback behaviour at the receiver depends on whether classic ECN
TCP feedback [RFC3168] or Accurate ECN (AccECN) TCP feedback TCP feedback [RFC3168] or Accurate ECN (AccECN) TCP feedback
[I-D.ietf-tcpm-accurate-ecn] has been negotiated. Nonetheless, [I-D.ietf-tcpm-accurate-ecn] has been negotiated. Nonetheless,
neither receiver feedback behaviour is altered by the present neither receiver feedback behaviour is altered by the present
specification. specification.
For each type of control packet or retransmission, the following For each type of control packet or retransmission, the following
sections detail changes to the sender's behaviour in two respects: i) sections detail changes to the sender's behaviour in two respects: i)
whether it sets ECT; and ii) its response to congestion feedback. whether it sets ECT; and ii) its response to congestion feedback.
Table 1 summarises these two behaviours for each type of packet, but Table 1 summarises these two behaviours for each type of packet, but
the relevant subsection below should be referred to for the detailed the relevant subsection below should be referred to for the detailed
behaviour. The subsection on the SYN is more complex than the behaviour. The subsection on the SYN is more complex than the
others, because it has to include fall-back behaviour if the ECT others, because it has to include fall-back behaviour if the ECT
packet appears not to have got through, and caching of the outcome to packet appears not to have got through, and caching of the outcome to
detect persistent failures. detect persistent failures.
+-----------+-----------------+-----------------+-------------------+ +---------+-----------------+------------------+--------------------+
| TCP | ECN field if | ECN field if | Congestion | | TCP | ECN field if | ECN field if | Congestion |
| packet | AccECN f/b | RFC3168 f/b | Response | | packet | AccECN f/b | RFC3168 f/b | Response |
| type | negotiated* | negotiated* | | | type | negotiated* | negotiated* | |
+-----------+-----------------+-----------------+-------------------+ +---------+-----------------+------------------+--------------------+
| SYN | ECT | not-ECT | Reduce IW | | SYN | ECT | not-ECT | Reduce IW |
| | | | | | | | | |
| SYN-ACK | ECT | ECT | Reduce IW as in | | SYN-ACK | ECT | ECT | Reduce IW |
| [RFC5562] | | | [RFC5562] | | | | | |
| | | | | | Pure | ECT | ECT | Usual cwnd |
| Pure ACK | ECT | ECT | Usual cwnd | | ACK | | | response and |
| | | | response and | | | | | optionally |
| | | | optionally | | | | | [RFC5690] |
| | | | [RFC5690] | | | | | |
| | | | | | W Probe | ECT | ECT | Usual cwnd |
| W Probe | ECT | ECT | Usual cwnd | | | | | response |
| | | | response | | | | | |
| | | | | | FIN | ECT | ECT | None or optionally |
| FIN | ECT | ECT | None or | | | | | [RFC5690] |
| | | | optionally | | | | | |
| | | | [RFC5690] | | RST | ECT | ECT | N/A |
| | | | | | | | | |
| RST | ECT | ECT | N/A | | Re-XMT | ECT | ECT | Usual cwnd |
| | | | | | | | | response |
| Re-XMT | ECT | ECT | Usual cwnd | +---------+-----------------+------------------+--------------------+
| | | | response |
+-----------+-----------------+-----------------+-------------------+
Window probe and retransmission are abbreviated to W Probe an Re-XMT. Window probe and retransmission are abbreviated to W Probe an Re-XMT.
* For a SYN, "negotiated" means "requested". * For a SYN, "negotiated" means "requested".
Table 1: Summary of sender behaviour. In each case the relevant Table 1: Summary of sender behaviour. In each case the relevant
section below should be referred to for the detailed behaviour section below should be referred to for the detailed behaviour
It can be seen that the sender can set ECT in all cases, except if it It can be seen that the sender can set ECT in all cases, except if it
is not requesting AccECN feedback on the SYN. Therefore it is is not requesting AccECN feedback on the SYN. Therefore it is
RECOMMENDED that the experimental AccECN specification RECOMMENDED that the experimental AccECN specification
skipping to change at page 8, line 37 skipping to change at page 9, line 20
attempts to negotiate Accurate ECN feedback in the same SYN. attempts to negotiate Accurate ECN feedback in the same SYN.
For the experiments proposed here, if the SYN is requesting AccECN For the experiments proposed here, if the SYN is requesting AccECN
feedback, the TCP sender will also set ECT on the SYN. It can ignore feedback, the TCP sender will also set ECT on the SYN. It can ignore
the prohibition in section 6.1.1 of RFC 3168 against setting ECT on the prohibition in section 6.1.1 of RFC 3168 against setting ECT on
such a SYN. such a SYN.
The following subsections about the SYN solely apply to this case The following subsections about the SYN solely apply to this case
where the initiator sent an ECT SYN. where the initiator sent an ECT SYN.
MEASUREMENTS NEEDED: Measurements are needed to verify that if SYN 3.2.1.2. Caching Lack of AccECN Support for ECT on SYNs
packets with the ECT(0)/ECT(1)/CE codepoints are properly
delivered by the network. We need to learn if there are cases if
SYN packets are dropped because having the the ECT(0)/ECT(1)/CE
codepoints. We also need to learn if the network clears SYN
packet with the the ECT(0)/ECT(1)/CE codepoints. In addition, we
need measurements to learn how current deployed base of servers
react to SYN packets with ECT(0)/ECT(1)/CE codepoints whether they
discard it, or process it an return a SYN/ACK packet proceeding
with the connection. It would be also useful to measure how the
network elements and the servers react to all possible
combinations of ECN codepoints and NS/CWR/ECE flags.
3.2.1.2. Caching Lack of Support for ECT on SYNs
Until AccECN servers become widely deployed, a TCP initiator that Until AccECN servers become widely deployed, a TCP initiator that
sets ECT on a SYN (which implies the same SYN also requests AccECN, sets ECT on a SYN (which implies the same SYN also requests AccECN,
as required above) SHOULD also maintain a cache per server to record as required above) SHOULD also maintain a cache entry per server to
any failure of previous attempts. record that the server does not support AccECN and therefore has no
logic for congestion markings on the SYN. Mobile hosts MAY maintain
a cache entry per access network to record lack of AccECN support by
proxies (see Section 4.2.1).
The initiator will record any server's SYN-ACK response that does not The initiator will record any server's SYN-ACK response that does not
support AccECN. Subsequently the initiator will not set ECT on a SYN support AccECN. Subsequently the initiator will not set ECT on a SYN
to such a server, but it can still always request AccECN support to such a server, but it can still always request AccECN support
(because the response will state any earlier stage of ECN evolution (because the response will state any earlier stage of ECN evolution
that the server supports with no performance penalty). The initiator that the server supports with no performance penalty). The initiator
will discover a server that has upgraded to support AccECN as soon as will discover a server that has upgraded to support AccECN as soon as
it next connects, then it can remove the server from its cache and it next connects, then it can remove the server from its cache and
subsequently always set ECT for that server. subsequently always set ECT for that server.
skipping to change at page 9, line 46 skipping to change at page 10, line 16
scenarios. scenarios.
3.2.1.3. SYN Congestion Response 3.2.1.3. SYN Congestion Response
If the SYN-ACK returned to the TCP initiator confirms that the server If the SYN-ACK returned to the TCP initiator confirms that the server
supports AccECN, it will also indicate whether or not the SYN was CE- supports AccECN, it will also indicate whether or not the SYN was CE-
marked. If the SYN was CE-marked, the initiator MUST reduce its marked. If the SYN was CE-marked, the initiator MUST reduce its
Initial Window (IW) and SHOULD reduce it to 1 SMSS (sender maximum Initial Window (IW) and SHOULD reduce it to 1 SMSS (sender maximum
segment size). segment size).
If the SYN-ACK shows that the server does not support AccECN, the TCP If ECT has been set on the SYN and if the SYN-ACK shows that the
initiator MUST conservatively reduce its Initial Window and SHOULD server does not support AccECN, the TCP initiator MUST conservatively
reduce it to 1 SMSS. A reduction to greater than 1 SMSS MAY be reduce its Initial Window and SHOULD reduce it to 1 SMSS. A
appropriate (see Section 4.2.1). Conservatism is necessary because a reduction to greater than 1 SMSS MAY be appropriate (see
non-AccECN SYN-ACK cannot show whether the SYN was CE-marked. Section 4.2.1). Conservatism is necessary because a non-AccECN SYN-
ACK cannot show whether the SYN was CE-marked.
If the TCP initiator (host A) receives a SYN from the remote end If the TCP initiator (host A) receives a SYN from the remote end
(host B) after it has sent a SYN to B, it indicates the (unusual) (host B) after it has sent a SYN to B, it indicates the (unusual)
case of a simultaneous open. Host A will respond with a SYN-ACK. case of a simultaneous open. Host A will respond with a SYN-ACK.
Host A will probably then receive a SYN-ACK in response to its own Host A will probably then receive a SYN-ACK in response to its own
SYN, after which it can follow the appropriate one of the two SYN, after which it can follow the appropriate one of the two
paragraphs above. paragraphs above.
In all the above cases, the initiator does not have to back off its In all the above cases, the initiator does not have to back off its
retransmission timer as it would in response to a timeout following retransmission timer as it would in response to a timeout following
skipping to change at page 10, line 25 skipping to change at page 10, line 43
ACK have been successfully delivered through the network. Also, the ACK have been successfully delivered through the network. Also, the
initiator does not need to exit slow start or reduce ssthresh, which initiator does not need to exit slow start or reduce ssthresh, which
is not even required when a SYN is lost [RFC5681]. is not even required when a SYN is lost [RFC5681].
If an initial window of 10 (IW10 [RFC6928]) is implemented, Section 5 If an initial window of 10 (IW10 [RFC6928]) is implemented, Section 5
gives additional recommendations. gives additional recommendations.
3.2.1.4. Fall-Back Following No Response to an ECT SYN 3.2.1.4. Fall-Back Following No Response to an ECT SYN
An ECT SYN might be lost due to an over-zealous path element (or An ECT SYN might be lost due to an over-zealous path element (or
server) blocking ECT packets that do not conform to RFC 3168. server) blocking ECT packets that do not conform to RFC 3168. Some
However, loss is commonplace for numerous other reasons, e.g. evidence of this was found in a 2014 study [ecn-pam], but in a more
congestion loss at a non-ECN queue on the forward or reverse path, recent 2017 study {ToDo: Add reference (under submission)} extensive
transmission errors, etc. Alternatively, the cause of the blockage measurements found no case where ECT on TCP control packets was
might be the attempt to negotiate AccECN, or possibly other unrelated treated any differently from ECT on TCP data packets. Loss is
options on the SYN. commonplace for numerous other reasons, e.g. congestion loss at a
non-ECN queue on the forward or reverse path, transmission errors,
etc. Alternatively, the cause of the loss might be the attempt to
negotiate AccECN, or possibly other unrelated options on the SYN.
To expedite connection set-up if, after sending an ECT SYN, the Therefore, if the timer expires after the TCP initiator has sent the
retransmission timer expires, the TCP initiator SHOULD send a SYN first ECT SYN, it SHOULD make one more attempt to retransmit the SYN
with the not-ECT codepoint in the IP header. If other experimental with ECT set (backing off the timer as usual). If the retransmission
fields or options were on the SYN, it will also be necessary to timer expires again, it SHOULD retransmit the SYN with the not-ECT
follow their specifications for fall-back too. It would make sense codepoint in the IP header, to expedite connection set-up. If other
to co- ordinate all the strategies for fall-back in order to isolate experimental fields or options were on the SYN, it will also be
the specific cause of the problem. necessary to follow their specifications for fall-back too. It would
make sense to coordinate all the strategies for fall-back in order to
isolate the specific cause of the problem.
If the TCP initiator is caching failed connection attempts, it SHOULD If the TCP initiator is caching failed connection attempts, it SHOULD
NOT give up using ECT on the first SYN of subsequent connection NOT give up using ECT on the first SYN of subsequent connection
attempts until it is clear that the blockage persistently and attempts until it is clear that a blockage persistently and
specifically affects ECT on SYNs. This is because loss is so specifically affects ECT on SYNs. This is because loss is so
commonplace for other reasons. Even if it does eventually decide to commonplace for other reasons. Even if it does eventually decide to
give up on ECT on the SYN, it will probably not need to give up on give up setting ECT on the SYN, it will probably not need to give up
AccECN on the SYN. In any case, the cache should be arranged to on AccECN on the SYN. In any case, if a cache is used, it SHOULD be
expire so that the initiator will infrequently attempt to check arranged to expire so that the initiator will infrequently attempt to
whether the problem has been resolved. check whether the problem has been resolved.
Other fall-back strategies MAY be adopted where applicable (see Other fall-back strategies MAY be adopted where applicable (see
Section 4.2.2 for suggestions, and the conditions under which they Section 4.2.2 for suggestions, and the conditions under which they
would apply). would apply).
3.2.2. SYN-ACK 3.2.2. SYN-ACK
3.2.2.1. Setting ECT on the SYN-ACK 3.2.2.1. Setting ECT on the SYN-ACK
For the experiments proposed here, the TCP implementation will set For the experiments proposed here, the TCP implementation will set
skipping to change at page 12, line 10 skipping to change at page 12, line 34
is not even required when a SYN-ACK has been lost. is not even required when a SYN-ACK has been lost.
The congestion response to CE-marking on a SYN-ACK for a server that The congestion response to CE-marking on a SYN-ACK for a server that
implements either the TCP Fast Open experiment (TFO [RFC7413]) or the implements either the TCP Fast Open experiment (TFO [RFC7413]) or the
initial window of 10 experiment (IW10 [RFC6928]) is discussed in initial window of 10 experiment (IW10 [RFC6928]) is discussed in
Section 5. Section 5.
3.2.2.3. Fall-Back Following No Response to an ECT SYN-ACK 3.2.2.3. Fall-Back Following No Response to an ECT SYN-ACK
After the responder sends a SYN-ACK with ECT set, if its After the responder sends a SYN-ACK with ECT set, if its
retransmission timer expires it SHOULD resend a SYN-ACK with not-ECT retransmission timer expires it SHOULD retransmit one more SYN-ACK
set. If other experimental fields or options were on the SYN, it with ECT set (and back-off its timer as usual). If the timer expires
will also be necessary to follow their specifications for fall-back again, it SHOULD retransmit the SYN-ACK with not-ECT in the IP
too. It would make sense to co-ordinate all the strategies for fall- header. If other experimental fields or options were on the initial
back in order to isolate the specific cause of the problem. SYN-ACK, it will also be necessary to follow their specifications for
fall-back. It would make sense to co-ordinate all the strategies for
fall-back in order to isolate the specific cause of the problem.
The server MAY cache failed connection attempts, e.g. per client This fall-back strategy attempts to use ECT one more time than the
access network. If the TCP server is caching failed connection strategy for ECT SYN-ACKs in [RFC5562] (which is made obsolete, being
attempts, it SHOULD NOT give up using ECT on the first SYN-ACK of superseded by the present specification). Other fall-back strategies
subsequent connection attempts until it is clear that the blockage MAY be adopted if found to be more effective, e.g. fall-back to not-
persistently and specifically affects ECT on SYN-ACKs. This is ECT on the first retransmission attempt.
because loss is so commonplace for other reasons (see
Section 3.2.1.4). The cache should be arranged to expire so that the
server will infrequently attempt to check whether the problem has
been resolved.
This fall-back strategy is the same as that for ECT SYN-ACKs in The server MAY cache failed connection attempts, e.g. per client
[RFC5562]. Other fall-back strategies MAY be adopted if found to be access network. An client-based alternative to caching at the server
more effective, e.g. one retransmission attempt using ECT before is given in Section 4.3.2. If the TCP server is caching failed
reverting to not-ECT. connection attempts, it SHOULD NOT give up using ECT on the first
SYN-ACK of subsequent connection attempts until it is clear that the
blockage persistently and specifically affects ECT on SYN-ACKs. This
is because loss is so commonplace for other reasons (see
Section 3.2.1.4). If a cache is used, it SHOULD be arranged to
expire so that the server will infrequently attempt to check whether
the problem has been resolved.
3.2.3. Pure ACK 3.2.3. Pure ACK
For the experiments proposed here, the TCP implementation will set For the experiments proposed here, the TCP implementation will set
ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of
RFC 3168 to set not-ECT on a pure ACK. RFC 3168 to set not-ECT on a pure ACK.
A host that sets ECT on pure ACKs MUST reduce its congestion window A host that sets ECT on pure ACKs MUST reduce its congestion window
in response to any congestion feedback, in order to regulate any data in response to any congestion feedback, in order to regulate any data
segments it might be sending amongst the pure ACKs. It MAY also segments it might be sending amongst the pure ACKs. {ToDo: Reconsider
implement AckCC [RFC5690] to regulate the pure ACK rate, but this is this requirement in the light of WG comments.} It MAY also implement
not required. Note that, in comparison, TCP Congestion Control AckCC [RFC5690] to regulate the pure ACK rate, but this is not
[RFC5681] does not require a TCP to detect or respond to loss of pure required. Note that, in comparison, TCP Congestion Control [RFC5681]
ACKs at all; it requires no reduction in congestion window or ACK does not require a TCP to detect or respond to loss of pure ACKs at
rate. all; it requires no reduction in congestion window or ACK rate.
The question of whether the receiver of pure ACKs is required to feed The question of whether the receiver of pure ACKs is required to feed
back any CE marks on them is a matter for the relevant feedback back any CE marks on them is a matter for the relevant feedback
specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is
outside the scope of the present specification. Currently AccECN outside the scope of the present specification. Currently AccECN
feedback is required to count CE marking of any control packet feedback is required to count CE marking of any control packet
including pure ACKs. Whereas RFC 3168 is silent on this point, so including pure ACKs. Whereas RFC 3168 is silent on this point, so
feedback of CE-markings might be implementation specific (see feedback of CE-markings might be implementation specific (see
Section 4.4.1). Section 4.4.1).
DISCUSSION: An AccECN deployment or an implementation of RFC 3168 DISCUSSION: An AccECN deployment or an implementation of RFC 3168
that feeds back CE on pure ACKs will be at a disadvantage compared that feeds back CE on pure ACKs will be at a disadvantage compared
to an RFC 3168 implementation that does not. To solve this, the to an RFC 3168 implementation that does not. To solve this, the
WG could decide to prohibit setting ECT on pure ACKs unless AccECN WG could decide to prohibit setting ECT on pure ACKs unless AccECN
has been negotiated. If it does, the penultimate sentence of the has been negotiated. If it does, the penultimate sentence of the
Introduction will need to be modified. Introduction will need to be modified.
MEASUREMENTS NEEDED: Measurements are needed to learn how the MEASUREMENTS NEEDED: Measurements are needed to learn how the
deployed base of network elements and servers react to pure ACKs deployed base of network elements and RFC 3168 servers react to
marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether they are pure ACKs marked with the ECT(0)/ECT(1)/CE codepoints, i.e.
dropped, codepoint cleared or processed. whether they are dropped, codepoint cleared or processed and the
congestion indication fed back on a subsequent packet.
3.2.4. Window Probe 3.2.4. Window Probe
For the experiments proposed here, the TCP sender will set ECT on For the experiments proposed here, the TCP sender will set ECT on
window probes. It can ignore the prohibition in section 6.1.6 of RFC window probes. It can ignore the prohibition in section 6.1.6 of RFC
3168 against setting ECT on a window probe. 3168 against setting ECT on a window probe.
A window probe contains a single octet, so it is no different from a A window probe contains a single octet, so it is no different from a
regular TCP data segment. Therefore a TCP receiver will feed back regular TCP data segment. Therefore a TCP receiver will feed back
any CE marking on a window probe as normal (either using classic ECN any CE marking on a window probe as normal (either using classic ECN
feedback or AccECN feedback). The sender of the probe will then feedback or AccECN feedback). The sender of the probe will then
reduce its congestion window as normal. reduce its congestion window as normal.
A receive window of zero indicates that the application is not A receive window of zero indicates that the application is not
consuming data fast enough and does not imply anything about network consuming data fast enough and does not imply anything about network
congestion. Once the receive window opens, the congestion window congestion. Once the receive window opens, the congestion window
might become the limiting factor, so it is correct that CE-marked might become the limiting factor, so it is correct that CE-marked
probes reduce the congestion window. However, CE-marking on window probes reduce the congestion window. This complements cwnd
probes does not reduce the rate of the probes themselves. This is validation [RFC7661], which reduces cwnd as more time elapses without
unlikely to present a problem, given the duration between window having used available capacity. However, CE-marking on window probes
probes doubles [RFC1122] as long as the receiver is advertising a does not reduce the rate of the probes themselves. This is unlikely
zero window (currently minimum 1 second, maximum at least 1 minute to present a problem, given the duration between window probes
doubles [RFC1122] as long as the receiver is advertising a zero
window (currently minimum 1 second, maximum at least 1 minute
[RFC6298]). [RFC6298]).
MEASUREMENTS NEEDED: Measurements are needed to learn how the MEASUREMENTS NEEDED: Measurements are needed to learn how the
deployed base of network elements and servers react to Window deployed base of network elements and servers react to Window
probes marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether probes marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether
they are dropped, codepoint cleared or processed. they are dropped, codepoint cleared or processed.
3.2.5. FIN 3.2.5. FIN
A TCP implementation can set ECT on a FIN. A TCP implementation can set ECT on a FIN.
skipping to change at page 14, line 23 skipping to change at page 15, line 9
was CE-marked (whether using classic or AccECN feedback), reducing was CE-marked (whether using classic or AccECN feedback), reducing
the congestion window will not affect anything. the congestion window will not affect anything.
After sending a FIN, a host might send one or more pure ACKs. If it After sending a FIN, a host might send one or more pure ACKs. If it
is using one of the techniques in Section 3.2.3 to regulate the is using one of the techniques in Section 3.2.3 to regulate the
delayed ACK ratio for pure ACKs, it could equally be applied after a delayed ACK ratio for pure ACKs, it could equally be applied after a
FIN. But this is not required. FIN. But this is not required.
MEASUREMENTS NEEDED: Measurements are needed to learn how the MEASUREMENTS NEEDED: Measurements are needed to learn how the
deployed base of network elements and servers react to FIN packets deployed base of network elements and servers react to FIN packets
marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether they are marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether they
dropped, codepoint cleared or processed. are dropped, codepoint cleared or processed.
3.2.6. RST 3.2.6. RST
A TCP implementation can set ECT on a RST. A TCP implementation can set ECT on a RST.
The "challenge ACK" approach to checking the validity of RSTs The "challenge ACK" approach to checking the validity of RSTs
(section 3.2 of [RFC5961] is RECOMMENDED at the data receiver. (section 3.2 of [RFC5961] is RECOMMENDED at the data receiver.
A congestion response to a CE-marking on a RST is not required (and A congestion response to a CE-marking on a RST is not required (and
actually not possible). actually not possible).
MEASUREMENTS NEEDED: Measurements are needed to learn how the MEASUREMENTS NEEDED: Measurements are needed to learn how the
deployed base of network elements and servers react to RST packets deployed base of network elements and servers react to RST packets
marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether they are marked with the ECT(0)/ECT(1)/CE codepoints, i.e. whether they
dropped, codepoint cleared or processed. are dropped, codepoint cleared or processed.
3.2.7. Retransmissions 3.2.7. Retransmissions
For the experiments proposed here, the TCP sender will set ECT on For the experiments proposed here, the TCP sender will set ECT on
retransmitted segments. It can ignore the prohibition in section retransmitted segments. It can ignore the prohibition in section
6.1.5 of RFC 3168 against setting ECT on retransmissions. 6.1.5 of RFC 3168 against setting ECT on retransmissions.
Nonetheless, the TCP data receiver MUST ignore the CE codepoint on Nonetheless, the TCP data receiver MUST ignore the CE codepoint on
incoming segments that fail any validity check. The validity check incoming segments that fail any validity check. The validity check
in section 5.2 of [RFC5961] is RECOMMENDED. This will effectively in section 5.2 of [RFC5961] is RECOMMENDED. This will effectively
skipping to change at page 15, line 16 skipping to change at page 16, line 5
If the TCP sender receives feedback that a retransmitted packet was If the TCP sender receives feedback that a retransmitted packet was
CE-marked, it will react as it would to any feedback of CE-marking on CE-marked, it will react as it would to any feedback of CE-marking on
a data packet. a data packet.
MEASUREMENTS NEEDED: Measurements are needed to learn how the MEASUREMENTS NEEDED: Measurements are needed to learn how the
deployed base of network elements and servers react to deployed base of network elements and servers react to
retransmissions marked with the ECT(0)/ECT(1)/CE codepoints, i.e. retransmissions marked with the ECT(0)/ECT(1)/CE codepoints, i.e.
whether they are dropped, codepoint cleared or processed. whether they are dropped, codepoint cleared or processed.
3.2.8. General Fall-back for any Control Packet or Retransmission
Extensive measurements in fixed and mobile networks {ToDo: reference
(under submission)} have found no evidence of blockages due to ECT
being set on any type of TCP control packet.
In case traversal problems arise in future, fall-back measures have
been specified above, but only for the cases where ECT on the initial
packet of a half-connection (SYN or SYN-ACK) is persistently failing
to get through.
Fall-back measures for blockage of ECT on other TCP control packets
MAY be implemented. However they are not specified here given the
lack of any evidence they will be needed. Section 4.9 justifies this
advice in more detail.
4. Rationale 4. Rationale
This section is informative, not normative. It presents counter- This section is informative, not normative. It presents counter-
arguments against the justifications in the RFC series for disabling arguments against the justifications in the RFC series for disabling
ECN on TCP control segments and retransmissions. It also gives ECN on TCP control segments and retransmissions. It also gives
rationale for why ECT is safe on control segments that have not, so rationale for why ECT is safe on control segments that have not, so
far, been mentioned in the RFC series. First it addresses over- far, been mentioned in the RFC series. First it addresses over-
arching arguments used for most packet types, then it addresses the arching arguments used for most packet types, then it addresses the
specific arguments for each packet type in turn. specific arguments for each packet type in turn.
skipping to change at page 17, line 37 skipping to change at page 18, line 42
B. Cache failures: The optimistic ECT strategy can be B. Cache failures: The optimistic ECT strategy can be
improved by recording solely those servers that do not improved by recording solely those servers that do not
support AccECN. On subsequent connections to these non- support AccECN. On subsequent connections to these non-
AccECN servers, the initiator will still request AccECN AccECN servers, the initiator will still request AccECN
but not set ECT on the SYN. Then, the initiator can use but not set ECT on the SYN. Then, the initiator can use
its full initial window (if it has enough request data to its full initial window (if it has enough request data to
need it). Longer term, as servers upgrade to AccECN, the need it). Longer term, as servers upgrade to AccECN, the
initiator will remove them from the cache and use ECT on initiator will remove them from the cache and use ECT on
subsequent SYNs to that server. subsequent SYNs to that server.
Where an access network operator mediates Internet access
via a proxy that does not support AccECN, the optimistic
ECT strategy will always fail. This scenario is more
likely in mobile networks. Therefore, a mobile host could
cache lack of AccECN support per attached access network
operator. Whenever it attached to a new operator, it
could check a well-known AccECN test server and, if it
found no AccECN support, it would add a cache entry for
the attached operator. It would only use ECT when neither
network nor server were cached. It would only populate
its per server cache when not attached to a non-AccECN
proxy.
(S3): ECT by configuration: In a controlled environment, the (S3): ECT by configuration: In a controlled environment, the
administrator can make sure that servers support ECN-capable administrator can make sure that servers support ECN-capable
SYN packets. Examples of controlled environments are single- SYN packets. Examples of controlled environments are single-
tenant DCs, and possibly multi-tenant DCs if it is assumed tenant DCs, and possibly multi-tenant DCs if it is assumed
that each tenant mostly communicates with its own VMs. that each tenant mostly communicates with its own VMs.
For unmanaged environments like the public Internet, pragmatically For unmanaged environments like the public Internet, pragmatically
the choice is between strategies (S1) and (S2B): the choice is between strategies (S1) and (S2B):
o The "pessimistic ECT and cache successes" strategy (S1) suffers o The "pessimistic ECT and cache successes" strategy (S1) suffers
skipping to change at page 18, line 33 skipping to change at page 19, line 49
shrinks. shrinks.
MEASUREMENTS NEEDED: Measurements are needed to determine whether MEASUREMENTS NEEDED: Measurements are needed to determine whether
one or the other strategy would be sufficient for any particular one or the other strategy would be sufficient for any particular
client, or whether a particular client would need both strategies client, or whether a particular client would need both strategies
in different circumstances. in different circumstances.
4.2.2. Argument 1b: Unrecognized ECT on the SYN 4.2.2. Argument 1b: Unrecognized ECT on the SYN
Given, until now, ECT-marked SYN packets have been prohibited, it Given, until now, ECT-marked SYN packets have been prohibited, it
cannot be assumed they will be accepted. According to a study using cannot be assumed they will be accepted.
2014 data [ecn-pam] from a limited range of vantage points, out of
the top 1M Alexa web sites, 4791 (0.82%) IPv4 sites and 104 (0.61%)
IPv6 sites failed to establish a connection when they received a TCP
SYN with any ECN codepoint set in the IP header and the appropriate
ECN flags in the TCP header. Of these, about 41% failed to establish
a connection due to the ECN flags in the TCP header even with a Not-
ECT ECN field in the IP header (i.e. despite full compliance with RFC
3168). Therefore adding the ECN-capability to SYNs was increasing
connection establishment failures by about 0.4%.
MEASUREMENTS NEEDED: In order to get these failures fixed, data According to a study using 2014 data [ecn-pam] from a limited range
will be needed on which of the possible causes below is behind of vantage points, out of the top 1M Alexa web sites, 4791 (0.82%)
them. IPv4 sites and 104 (0.61%) IPv6 sites failed to establish a
connection when they received a TCP SYN with any ECN codepoint set in
the IP header and the appropriate ECN flags in the TCP header. Of
these, about 41% failed to establish a connection due to the ECN
flags in the TCP header even with a Not-ECT ECN field in the IP
header (i.e. despite full compliance with RFC 3168). Therefore
adding the ECN capability to SYNs was increasing connection
establishment failures by about 0.4%.
In a study using 2017 data from a wider range of fixed and mobile
vantage points to the top 500k Alexa servers, no case was found where
adding the ECN capability to a SYN increased the likelihood of
connection establishment failure {ToDo: reference (under
submission)}.
MEASUREMENTS NEEDED: More investigation is needed to understand
the different outcomes of the 2014 and 2017 studies.
RFC 3168 says "a host MUST NOT set ECT on SYN [...] packets", but it RFC 3168 says "a host MUST NOT set ECT on SYN [...] packets", but it
does not say what the responder should do if an ECN-capable SYN does not say what the responder should do if an ECN-capable SYN
arrives. So perhaps some responder implementations are checking that arrives. So, in the 2014 study, perhaps some responder
the SYN complies with RFC 3168, then silently ignoring non-compliant implementations were checking that the SYN complied with RFC 3168,
SYNs (or perhaps returning a RST). Also some middleboxes (e.g. then silently ignoring non-compliant SYNs (or perhaps returning a
RST). Also some middleboxes (e.g. firewalls) might have been
firewalls) might be discarding non-compliant SYNs. For the future, discarding non-compliant SYNs. For the future,
[I-D.ietf-tsvwg-ecn-experimentation] updates RFC 3168 to clarify that [I-D.ietf-tsvwg-ecn-experimentation] updates RFC 3168 to clarify that
middleboxes "SHOULD NOT" do this, but that does not alter the past. middleboxes "SHOULD NOT" do this, but that does not alter the past.
Whereas RSTs can be dealt with immediately, silent failures introduce Whereas RSTs can be dealt with immediately, silent failures introduce
a retransmission timeout delay (default 1 second) at the initiator a retransmission timeout delay (default 1 second) at the initiator
before it attempts any fall back strategy. Ironically, making SYNs before it attempts any fall back strategy. Ironically, making SYNs
ECN-capable is intended to avoid the timeout when a SYN is lost due ECN-capable is intended to avoid the timeout when a SYN is lost due
to congestion. Fortunately, where discard of ECN-capable SYNs is due to congestion. Fortunately, if there is any discard of ECN-capable
to policy it will occur predictably, not randomly like congestion. SYNs due to policy, it will occur predictably, not randomly like
So the initiator can avoid it by caching those sites that do not congestion. So the initiator can avoid it by caching those sites
support ECN-capable SYNs. This further justifies the use of the that do not support ECN-capable SYNs. This further justifies the use
"optimistic ECT and cache failures" strategy in Section 3.2.1. of the "optimistic ECT and cache failures" strategy in Section 3.2.1.
MEASUREMENTS NEEDED: Experiments are needed to determine whether MEASUREMENTS NEEDED: Experiments are needed to determine whether
blocking of ECT on SYNs is widespread, and how many occurrences of blocking of ECT on SYNs is widespread, and how many occurrences of
problems would be masked by how few cache entries. problems would be masked by how few cache entries.
If blocking is too widespread for the "optimistic ECT and cache If blocking is too widespread for the "optimistic ECT and cache
failures" strategy (S2B), the "pessimistic ECT and cache successes" failures" strategy (S2B), the "pessimistic ECT and cache successes"
strategy (Section 4.2.1) would be better. strategy (Section 4.2.1) would be better.
MEASUREMENTS NEEDED: Then measurements would be needed on whether MEASUREMENTS NEEDED: Then measurements would be needed on whether
failures were still widespread on the second connection attempt failures were still widespread on the third connection attempt
after the more careful ("pessimistic") first connection. after the more careful ("pessimistic") first and second attempts.
If so, it might be necessary to send a not-ECT SYN soon after the If so, it might be necessary to send a not-ECT SYN a short delay
first ECT SYN (possibly with a delay between them - effectively after an ECT SYN and only accept the non-ECT connection if it
reducing the retransmission timeout) and only accept the non-ECT returned first. This would reduce the performance penalty for those
connection if it returned first. This would reduce the performance deploying ECT SYN support.
penalty for those deploying ECT SYN support.
FOR DISCUSSION: If this becomes necessary, how much delay ought to FOR DISCUSSION: If this becomes necessary, how much delay ought to
be required before the second SYN? Certainly less than the be required before the second SYN? Certainly less than the
standard RTO (1 second). But more or less than the maximum RTT standard RTO (1 second). But more or less than the maximum RTT
expected over the surface of the earth (roughly 250ms)? Or even expected over the surface of the earth (roughly 250ms)? Or even
back-to-back? back-to-back?
However, based on the data above from [ecn-pam], even a cache of a However, based on the data above from [ecn-pam], even a cache of a
dozen or so sites ought to avoid all ECN-related performance problems dozen or so sites ought to avoid all ECN-related performance problems
with roughly the Alexa top thousand. So it is questionable whether with roughly the Alexa top thousand. So it is questionable whether
skipping to change at page 20, line 45 skipping to change at page 22, line 18
Further experiments are needed to test how much malicious hosts can Further experiments are needed to test how much malicious hosts can
use ECT to augment flooding attacks without triggering AQMs to turn use ECT to augment flooding attacks without triggering AQMs to turn
off ECN support (flying "just under the radar"). If it is found that off ECN support (flying "just under the radar"). If it is found that
ECT can only slightly augment flooding attacks, the risk of such ECT can only slightly augment flooding attacks, the risk of such
attacks will need to be weighed against the performance benefits of attacks will need to be weighed against the performance benefits of
ECT SYNs. ECT SYNs.
4.3. SYN-ACKs 4.3. SYN-ACKs
The proposed approach in Section 3.2.2 for experimenting with ECN- The proposed approach in Section 3.2.2 for experimenting with ECN-
capable SYN-ACKs is identical to the scheme called ECN+ [ECN-PLUS]. capable SYN-ACKs is effectively identical to the scheme called ECN+
In 2005, the ECN+ paper demonstrated that it could reduce the average [ECN-PLUS]. In 2005, the ECN+ paper demonstrated that it could
Web response time by an order of magnitude. It also argued that reduce the average Web response time by an order of magnitude. It
adding ECT to SYN-ACKs did not raise any new security also argued that adding ECT to SYN-ACKs did not raise any new
vulnerabilities. security vulnerabilities.
4.3.1. Response to Congestion on a SYN-ACK
The IETF has already specified an experiment with ECN-capable SYN-ACK The IETF has already specified an experiment with ECN-capable SYN-ACK
packets [RFC5562]. It was inspired by the ECN+ paper, but it packets [RFC5562]. It was inspired by the ECN+ paper, but it
specified a much more conservative congestion response to a CE-marked specified a much more conservative congestion response to a CE-marked
SYN-ACK, called ECN+/TryOnce. This required the server to reduce its SYN-ACK, called ECN+/TryOnce. This required the server to reduce its
initial window to 1 segment (like ECN+), but then the server had to initial window to 1 segment (like ECN+), but then the server had to
send a second SYN-ACK and wait for its ACK before it could continue send a second SYN-ACK and wait for its ACK before it could continue
with its initial window of 1 SMSS. The second SYN-ACK of this 5-way with its initial window of 1 SMSS. The second SYN-ACK of this 5-way
handshake had to carry no data, and had to disable ECN, but no handshake had to carry no data, and had to disable ECN, but no
justification was given for these last two aspects. justification was given for these last two aspects.
The present ECN experiment uses the ECN+ congestion response, not The present ECN experiment obsoletes RFC 5562 because it uses the
ECN+/TryOnce. First we argue against the rationale for ECN+/TryOnce ECN+ congestion response, not ECN+/TryOnce. First we argue against
given in sections 4.4 and 6.2 of [RFC5562]. It starts with a rather the rationale for ECN+/TryOnce given in sections 4.4 and 6.2 of
too literal interpretation of the requirement in RFC 3168 that says [RFC5562]. It starts with a rather too literal interpretation of the
TCP's response to a single CE mark has to be "essentially the same as requirement in RFC 3168 that says TCP's response to a single CE mark
the congestion control response to a *single* dropped packet." TCP's has to be "essentially the same as the congestion control response to
response to a dropped initial (SYN or SYN-ACK) packet is to wait for a *single* dropped packet." TCP's response to a dropped initial (SYN
the retransmission timer to expire (currently 1s). However, this or SYN-ACK) packet is to wait for the retransmission timer to expire
long delay assumes the worst case between two possible causes of the (currently 1s). However, this long delay assumes the worst case
loss: a) heavy overload; or b) the normal capacity-seeking behaviour between two possible causes of the loss: a) heavy overload; or b) the
of other TCP flows. When the network is still delivering CE-marked normal capacity-seeking behaviour of other TCP flows. When the
packets, it implies that there is an AQM at the bottleneck and that network is still delivering CE-marked packets, it implies that there
it is not overloaded. This is because an AQM under overload will is an AQM at the bottleneck and that it is not overloaded. This is
disable ECN (as recommended in section 7 of RFC 3168 and repeated in because an AQM under overload will disable ECN (as recommended in
section 4.2.1 of RFC 7567). So scenario (a) can be ruled out. section 7 of RFC 3168 and repeated in section 4.2.1 of RFC 7567). So
Therefore, TCP's response to a CE-marked SYN-ACK can be similar to scenario (a) can be ruled out. Therefore, TCP's response to a CE-
its response to the loss of _any_ packet, rather than backing off as marked SYN-ACK can be similar to its response to the loss of _any_
if the special _initial_ packet of a flow has been lost. packet, rather than backing off as if the special _initial_ packet of
a flow has been lost.
How TCP responds to the loss of any single packet depends what it has How TCP responds to the loss of any single packet depends what it has
just been doing. But there is not really a precedent for TCP's just been doing. But there is not really a precedent for TCP's
response when it experiences a CE mark having sent only one (small) response when it experiences a CE mark having sent only one (small)
packet. If TCP had been adding one segment per RTT, it would have packet. If TCP had been adding one segment per RTT, it would have
halved its congestion window, but it hasn't established a congestion halved its congestion window, but it hasn't established a congestion
window yet. If it had been exponentially increasing it would have window yet. If it had been exponentially increasing it would have
exited slow start, but it hasn't started exponentially increasing yet exited slow start, but it hasn't started exponentially increasing yet
so it hasn't established a slow-start threshold. so it hasn't established a slow-start threshold.
skipping to change at page 22, line 5 skipping to change at page 23, line 29
and it is probably already somewhere around the AQM's operating point and it is probably already somewhere around the AQM's operating point
- it is unlikely to be well below and it might be well above. So, it - it is unlikely to be well below and it might be well above. So, it
does not seem sensible to add a number of packets at once. On the does not seem sensible to add a number of packets at once. On the
other hand, it is highly unlikely that the SYN-ACK itself pushed the other hand, it is highly unlikely that the SYN-ACK itself pushed the
AQM into congestion, so it will be safe to introduce another single AQM into congestion, so it will be safe to introduce another single
segment immediately (1 RTT after the SYN-ACK). Therefore, starting segment immediately (1 RTT after the SYN-ACK). Therefore, starting
to probe for capacity with a slow start from an initial window of 1 to probe for capacity with a slow start from an initial window of 1
segment seems appropriate to the circumstances. This is the approach segment seems appropriate to the circumstances. This is the approach
adopted in Section 3.2.2. adopted in Section 3.2.2.
4.3.2. Fall-Back if ECT SYN-ACK Fails
An alternative to the server caching failed connection attempts would
be for the server to rely on the client caching failed attempts (on
the basis that the client would cache a failure whether ECT was
blocked on the SYN or the SYN-ACK). This strategy cannot be used if
the SYN does not request AccECN support. It works as follows: if the
server receives a SYN that requests AccECN support but is set to not-
ECT, it replies with a SYN-ACK also set to not-ECT. If a middlebox
only blocks ECT on SYNs, not SYN-ACKs, this strategy might disable
ECN on a SYN-ACK when it did not need to, but at least it saves the
server from maintaining a cache.
4.4. Pure ACKs 4.4. Pure ACKs
Section 5.2 of RFC 3168 gives the following arguments for not Section 5.2 of RFC 3168 gives the following arguments for not
allowing the ECT marking of pure ACKs (ACKs not piggy-backed on allowing the ECT marking of pure ACKs (ACKs not piggy-backed on
data): data):
"To ensure the reliable delivery of the congestion indication of "To ensure the reliable delivery of the congestion indication of
the CE codepoint, an ECT codepoint MUST NOT be set in a packet the CE codepoint, an ECT codepoint MUST NOT be set in a packet
unless the loss of that packet in the network would be detected by unless the loss of that packet in the network would be detected by
the end nodes and interpreted as an indication of congestion. the end nodes and interpreted as an indication of congestion.
skipping to change at page 24, line 17 skipping to change at page 25, line 51
normal. normal.
* AccECN feedback: the receiver continually feeds back a count of * AccECN feedback: the receiver continually feeds back a count of
the number of CE-marked packets that it has received (and, if the number of CE-marked packets that it has received (and, if
possible, a count of CE-marked bytes). possible, a count of CE-marked bytes).
Congestion response: In either case (classic or AccECN feedback), if Congestion response: In either case (classic or AccECN feedback), if
the TCP sender does receive feedback about CE-markings on pure the TCP sender does receive feedback about CE-markings on pure
ACKs, it will react in the usual way by reducing its congestion ACKs, it will react in the usual way by reducing its congestion
window accordingly. This will regulate the rate of any data window accordingly. This will regulate the rate of any data
packets it is sending amongst the pure ACKs. packets it is sending amongst the pure ACKs. Note that, while a
host has no application data to send, any congestion window it has
attained might also be reduced by the congestion window validation
mechanism [RFC7661].
4.4.2. ACK Rate Response to CE-Marked Pure ACKs 4.4.2. ACK Rate Response to CE-Marked Pure ACKs
Reducing the congestion window will have no effect on the rate of Reducing the congestion window will have no effect on the rate of
pure ACKs. The worst case here is if the bottleneck is congested pure ACKs. The worst case here is if the bottleneck is congested
solely with pure ACKs, but it could also be problematic if a large solely with pure ACKs, but it could also be problematic if a large
fraction of the load was from unresponsive ACKs, leaving little or no fraction of the load was from unresponsive ACKs, leaving little or no
capacity for the load from responsive data. capacity for the load from responsive data.
Since RFC 3168 was published, Acknowledgement Congestion Control Since RFC 3168 was published, Acknowledgement Congestion Control
skipping to change at page 28, line 40 skipping to change at page 30, line 31
(it would have reduced its congestion window already when it (it would have reduced its congestion window already when it
retransmitted the packet). Whereas, if retransmitted packets can be retransmitted the packet). Whereas, if retransmitted packets can be
CE tagged instead of dropped, senders could potentially react more CE tagged instead of dropped, senders could potentially react more
than once to congestion. However, we argue that it is legitimate to than once to congestion. However, we argue that it is legitimate to
respond again to congestion if it still persists in subsequent round respond again to congestion if it still persists in subsequent round
trip(s). trip(s).
Therefore, in all three cases, it is not incorrect to set ECT on Therefore, in all three cases, it is not incorrect to set ECT on
retransmissions. retransmissions.
5. Interaction with popular variants or derivatives of TCP 4.9. General Fall-back for any Control Packet
The following subsections discuss any interactions between setting Extensive experiments have found no evidence of any traversal
ECT on all all packets and using the following popular variants or problems with ECT on any TCP control packet {ToDo: reference (under
derivatives of TCP: SCTP, IW10 and TFO. This section is informative submission)}. Nonetheless, Sections 3.2.1.4 and 3.2.2.3 specify fall-
not normative, because no interactions have been identified that back measures if ECT on the first packet of each half-connection (SYN
require any change to specifications. The subsection on IW10 or SYN-ACK) appears to be blocking progress. Here, the question of
discusses potential changes to specifications but recommends that no fall-back measures for ECT on other control packets is explored. It
changes are needed. supports the advice given in Section 3.2.8; until there's evidence
that something's broken, don't fix it.
TCP variants that have been assessed and found not to interact If an implementation has had to disable ECT to ensure the first
adversely with ECT on TCP control packets are: SYN cookies (see packet of a flow (SYN or SYN-ACK) gets through, the question arises
Appendix A of [RFC4987] and section 3.1 of [RFC5562]), TCP Fast Open whether it ought to disable ECT on all subsequent control packets
(TFO [RFC7413]) and L4S [I-D.briscoe-tsvwg-l4s-arch]. within the same TCP connection. Without evidence of any such
problems, this seems unnecessarily cautious. Particularly given it
would be hard to detect loss of most other types of TCP control
packets that are not ACK'd. And particularly given that
unnecessarily removing ECT from other control packets could lead to
performance problems, e.g. by directing them into an inferior queue
[I-D.ietf-tsvwg-ecn-l4s-id] or over a different path, because some
broken multipath equipment (erroneously) routes based on all 8 bits
of the Diffserv field.
5.1. SCTP In the case where a connection starts without ECT on the SYN (perhaps
because problems with previous connections had been cached), there
will have been no test for ECT traversal in the client-server
direction until the pure ACK that completes the handshake. It is
possible that some middlebox might block ECT on this pure ACK or on
later retransmissions of lost packets. Similarly, after a route
change, the new path might include some middlebox that blocks ECT on
some or all TCP control packets. However, without evidence of such
problems, the complexity of a fix does not seem worthwhile.
Stream Control Transmission Protocol (SCTP [RFC4960]) is a standards MORE MEASUREMENTS NEEDED (?): If further two-ended measurements do
track protocol derived from TCP. SCTP currently does not include ECN find evidence for these traversal problems, measurements would be
support, but Appendix A of RFC 4960 broadly describes how it would be needed to check for correlation of ECT traversal problems between
supported and a draft on the addition of ECN to SCTP has been different control packets. It might then be necessary to
produced [I-D.stewart-tsvwg-sctpecn]. This draft avoids setting ECT introduce a catch-all fall-back rule that disables ECT on certain
on control packets and retransmissions, closely following the subsequent TCP control packets based on some criteria developed
arguments in RFC 3168. When ECN is finally added to SCTP, experience from these measurements.
from experiments on adding ECN support to all TCP packets ought to be
directly transferable to SCTP.
5.2. IW10 5. Interaction with popular variants or derivatives of TCP
The following subsections discuss any interactions between setting
ECT on all packets and using the following popular variants of TCP:
IW10 and TFO. It also briefly notes the possibility that the
principles applied here should translate to protocols derived from
TCP. This section is informative not normative, because no
interactions have been identified that require any change to
specifications. The subsection on IW10 discusses potential changes
to specifications but recommends that no changes are needed.
The designs of the following TCP variants have also been assessed and
found not to interact adversely with ECT on TCP control packets: SYN
cookies (see Appendix A of [RFC4987] and section 3.1 of [RFC5562]),
TCP Fast Open (TFO [RFC7413]) and L4S [I-D.ietf-tsvwg-l4s-arch].
5.1. IW10
IW10 is an experiment to determine whether it is safe for TCP to use IW10 is an experiment to determine whether it is safe for TCP to use
an initial window of 10 SMSS [RFC6928]. an initial window of 10 SMSS [RFC6928].
This subsection does not recommend any additions to the present This subsection does not recommend any additions to the present
specification in order to interwork with IW10. The specifications as specification in order to interwork with IW10. The specifications as
they stand are safe, and there is only a corner-case with ECT on the they stand are safe, and there is only a corner-case with ECT on the
SYN where performance could be occasionally improved, as explained SYN where performance could be occasionally improved, as explained
below. below.
skipping to change at page 30, line 11 skipping to change at page 32, line 32
o currently it is not common for a TCP initiator (client) to have o currently it is not common for a TCP initiator (client) to have
more than one data segment to send {ToDo: evidence/reference?} - more than one data segment to send {ToDo: evidence/reference?} -
IW10 is primarily exploited by TCP servers. IW10 is primarily exploited by TCP servers.
If a responder receives feedback that the SYN-ACK was CE-marked, If a responder receives feedback that the SYN-ACK was CE-marked,
Section 3.2.2.2 mandates that it reduces its initial window to 1 Section 3.2.2.2 mandates that it reduces its initial window to 1
SMSS. When the responder also implements IW10, it is particularly SMSS. When the responder also implements IW10, it is particularly
important to adhere to this requirement in order to avoid overflowing important to adhere to this requirement in order to avoid overflowing
a queue that is clearly already congested. a queue that is clearly already congested.
5.3. TFO 5.2. TFO
TCP Fast Open (TFO [RFC7413]) is an experiment to remove the round TCP Fast Open (TFO [RFC7413]) is an experiment to remove the round
trip delay of TCP's 3-way hand-shake (3WHS). A TFO initiator caches trip delay of TCP's 3-way hand-shake (3WHS). A TFO initiator caches
a cookie from a previous connection with a TFO-enabled server. Then, a cookie from a previous connection with a TFO-enabled server. Then,
for subsequent connections to the same server, any data included on for subsequent connections to the same server, any data included on
the SYN can be passed directly to the server application, which can the SYN can be passed directly to the server application, which can
then return up to an initial window of response data on the SYN-ACK then return up to an initial window of response data on the SYN-ACK
and on data segments straight after it, without waiting for the ACK and on data segments straight after it, without waiting for the ACK
that completes the 3WHS. that completes the 3WHS.
skipping to change at page 30, line 33 skipping to change at page 33, line 5
TCP control packets can be combined without altering either TCP control packets can be combined without altering either
specification, which is justified as follows: specification, which is justified as follows:
o The handling of ECN marking on a SYN is no different whether or o The handling of ECN marking on a SYN is no different whether or
not it carries data. not it carries data.
o In response to any CE-marking on the SYN-ACK, the responder adopts o In response to any CE-marking on the SYN-ACK, the responder adopts
the normal response to congestion, as discussed in Section 7.2 of the normal response to congestion, as discussed in Section 7.2 of
[RFC7413]. [RFC7413].
5.3. TCP Derivatives
Stream Control Transmission Protocol (SCTP [RFC4960]) is a standards
track transport protocol derived from TCP. SCTP currently does not
include ECN support, but Appendix A of RFC 4960 broadly describes how
it would be supported and a (long-expired) draft on the addition of
ECN to SCTP has been produced [I-D.stewart-tsvwg-sctpecn]. This
draft avoided setting ECT on control packets and retransmissions,
closely following the arguments in RFC 3168.
QUIC [I-D.ietf-quic-transport] is another standards track transport
protocol offering similar services to TCP but intended to exploit
some of the benefits of running over UDP. A way to add ECN support
to QUIC has been proposed [I-D.johansson-quic-ecn].
Experience from experiments on adding ECN support to all TCP packets
ought to be directly transferable to derivatives of TCP, like SCTP or
QUIC.
6. Security Considerations 6. Security Considerations
Section 3.2.6 considers the question of whether ECT on RSTs will Section 3.2.6 considers the question of whether ECT on RSTs will
allow RST attacks to be intensified. There are several security allow RST attacks to be intensified. There are several security
arguments presented in RFC 3168 for preventing the ECN marking of TCP arguments presented in RFC 3168 for preventing the ECN marking of TCP
control packets and retransmitted segments. We believe all of them control packets and retransmitted segments. We believe all of them
have been properly addressed in Section 4, particularly Section 4.2.3 have been properly addressed in Section 4, particularly Section 4.2.3
and Section 4.8 on DoS attacks using spoofed ECT-marked SYNs and and Section 4.8 on DoS attacks using spoofed ECT-marked SYNs and
spoofed CE-marked retransmissions. spoofed CE-marked retransmissions.
7. IANA Considerations 7. IANA Considerations
There are no IANA considerations in this memo. There are no IANA considerations in this memo.
8. Acknowledgments 8. Acknowledgments
Thanks to Mirja Kuehlewind and David Black for their useful reviews. Thanks to Mirja Kuehlewind, David Black, Padma Bhooma and Gorry
Fairhurst for their useful reviews.
The work of Marcelo Bagnulo has been performed in the framework of The work of Marcelo Bagnulo has been performed in the framework of
the H2020-ICT-2014-2 project 5G NORMA. His contribution reflects the the H2020-ICT-2014-2 project 5G NORMA. His contribution reflects the
consortiums view, but the consortium is not liable for any use that consortium's view, but the consortium is not liable for any use that
may be made of any of the information contained therein. may be made of any of the information contained therein.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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-03 (work in progress), May 2017. ecn-03 (work in progress), May 2017.
[I-D.ietf-tsvwg-ecn-experimentation] [I-D.ietf-tsvwg-ecn-experimentation]
Black, D., "Explicit Congestion Notification (ECN) Black, D., "Explicit Congestion Notification (ECN)
Experimentation", draft-ietf-tsvwg-ecn-experimentation-05 Experimentation", draft-ietf-tsvwg-ecn-experimentation-06
(work in progress), August 2017. (work in progress), September 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[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,
<https://www.rfc-editor.org/info/rfc5562>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010, DOI 10.17487/RFC5961, August 2010,
<https://www.rfc-editor.org/info/rfc5961>. <https://www.rfc-editor.org/info/rfc5961>.
9.2. Informative References 9.2. Informative References
[ecn-pam] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., [ecn-pam] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I.,
Fairhurst, G., and R. Scheffenegger, "Enabling Internet- Fairhurst, G., and R. Scheffenegger, "Enabling Internet-
Wide Deployment of Explicit Congestion Notification", Wide Deployment of Explicit Congestion Notification",
Int'l Conf. on Passive and Active Network Measurement Int'l Conf. on Passive and Active Network Measurement
(PAM'15) pp193-205, 2015. (PAM'15) pp193-205, 2015.
[ECN-PLUS] [ECN-PLUS]
Kuzmanovic, A., "The Power of Explicit Congestion Kuzmanovic, A., "The Power of Explicit Congestion
Notification", ACM SIGCOMM 35(4):61--72, 2005. Notification", ACM SIGCOMM 35(4):61--72, 2005.
[I-D.briscoe-tsvwg-ecn-l4s-id] [I-D.ietf-quic-transport]
Schepper, K., Briscoe, B., and I. Tsang, "Identifying Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
Modified Explicit Congestion Notification (ECN) Semantics and Secure Transport", draft-ietf-quic-transport-06 (work
for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- in progress), September 2017.
id-02 (work in progress), October 2016.
[I-D.briscoe-tsvwg-l4s-arch] [I-D.ietf-tcpm-dctcp]
Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work
in progress), August 2017.
[I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-00
(work in progress), May 2017.
[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-briscoe-tsvwg-l4s-arch-02 (work in Architecture", draft-ietf-tsvwg-l4s-arch-00 (work in
progress), March 2017. progress), May 2017.
[I-D.johansson-quic-ecn]
Johansson, I., "ECN support in QUIC", draft-johansson-
quic-ecn-03 (work in progress), May 2017.
[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.
[judd-nsdi] [judd-nsdi]
Judd, G., "Attaining the promise and avoiding the pitfalls Judd, G., "Attaining the promise and avoiding the pitfalls
of TCP in the Datacenter", USENIX Symposium on Networked of TCP in the Datacenter", USENIX Symposium on Networked
Systems Design and Implementation (NSDI'15) pp.145-157, Systems Design and Implementation (NSDI'15) pp.145-157,
skipping to change at page 33, line 5 skipping to change at page 36, line 13
<https://www.rfc-editor.org/info/rfc3540>. <https://www.rfc-editor.org/info/rfc3540>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[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,
<https://www.rfc-editor.org/info/rfc5562>.
[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>.
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
Acknowledgement Congestion Control to TCP", RFC 5690, Acknowledgement Congestion Control to TCP", RFC 5690,
DOI 10.17487/RFC5690, February 2010, DOI 10.17487/RFC5690, February 2010,
<https://www.rfc-editor.org/info/rfc5690>. <https://www.rfc-editor.org/info/rfc5690>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
skipping to change at page 33, line 33 skipping to change at page 36, line 47
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015,
<https://www.rfc-editor.org/info/rfc7661>.
Authors' Addresses Authors' Addresses
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: 34 91 6249500 Phone: 34 91 6249500
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es URI: http://www.it.uc3m.es
Bob Briscoe Bob Briscoe
Simula Research Lab CableLabs
UK
Email: ietf@bobbriscoe.net Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
 End of changes. 60 change blocks. 
279 lines changed or deleted 421 lines changed or added

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