draft-ietf-tcpm-accurate-ecn-04.txt   draft-ietf-tcpm-accurate-ecn-05.txt 
TCP Maintenance & Minor Extensions (tcpm) B. Briscoe TCP Maintenance & Minor Extensions (tcpm) B. Briscoe
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Experimental M. Kuehlewind Intended status: Experimental M. Kuehlewind
Expires: May 3, 2018 ETH Zurich Expires: May 15, 2018 ETH Zurich
R. Scheffenegger R. Scheffenegger
October 30, 2017 November 11, 2017
More Accurate ECN Feedback in TCP More Accurate ECN Feedback in TCP
draft-ietf-tcpm-accurate-ecn-04 draft-ietf-tcpm-accurate-ecn-05
Abstract Abstract
Explicit Congestion Notification (ECN) is a mechanism where network Explicit Congestion Notification (ECN) is a mechanism where network
nodes can mark IP packets instead of dropping them to indicate nodes can mark IP packets instead of dropping them to indicate
incipient congestion to the end-points. Receivers with an ECN- incipient congestion to the end-points. Receivers with an ECN-
capable transport protocol feed back this information to the sender. capable transport protocol feed back this information to the sender.
ECN is specified for TCP in such a way that only one feedback signal ECN is specified for TCP in such a way that only one feedback signal
can be transmitted per Round-Trip Time (RTT). Recently, new TCP can be transmitted per Round-Trip Time (RTT). Recently, new TCP
mechanisms like Congestion Exposure (ConEx) or Data Center TCP mechanisms like Congestion Exposure (ConEx) or Data Center TCP
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 May 3, 2018. This Internet-Draft will expire on May 15, 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 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Roadmap . . . . . . . . . . . . . . . . . . . . 4 1.1. Document Roadmap . . . . . . . . . . . . . . . . . . . . 4
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Experiment Goals . . . . . . . . . . . . . . . . . . . . 5 1.3. Experiment Goals . . . . . . . . . . . . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Recap of Existing ECN feedback in IP/TCP . . . . . . . . 6 1.5. Recap of Existing ECN feedback in IP/TCP . . . . . . . . 6
2. AccECN Protocol Overview and Rationale . . . . . . . . . . . 7 2. AccECN Protocol Overview and Rationale . . . . . . . . . . . 7
2.1. Capability Negotiation . . . . . . . . . . . . . . . . . 8 2.1. Capability Negotiation . . . . . . . . . . . . . . . . . 9
2.2. Feedback Mechanism . . . . . . . . . . . . . . . . . . . 9 2.2. Feedback Mechanism . . . . . . . . . . . . . . . . . . . 9
2.3. Delayed ACKs and Resilience Against ACK Loss . . . . . . 9 2.3. Delayed ACKs and Resilience Against ACK Loss . . . . . . 9
2.4. Feedback Metrics . . . . . . . . . . . . . . . . . . . . 10 2.4. Feedback Metrics . . . . . . . . . . . . . . . . . . . . 10
2.5. Generic (Dumb) Reflector . . . . . . . . . . . . . . . . 11 2.5. Generic (Dumb) Reflector . . . . . . . . . . . . . . . . 11
3. AccECN Protocol Specification . . . . . . . . . . . . . . . . 11 3. AccECN Protocol Specification . . . . . . . . . . . . . . . . 12
3.1. Negotiating to use AccECN . . . . . . . . . . . . . . . . 12 3.1. Negotiating to use AccECN . . . . . . . . . . . . . . . . 12
3.1.1. Negotiation during the TCP handshake . . . . . . . . 12 3.1.1. Negotiation during the TCP handshake . . . . . . . . 12
3.1.2. Retransmission of the SYN . . . . . . . . . . . . . . 14 3.1.2. Retransmission of the SYN . . . . . . . . . . . . . . 14
3.2. AccECN Feedback . . . . . . . . . . . . . . . . . . . . . 15 3.2. AccECN Feedback . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. Initialization of Feedback Counters at the Data 3.2.1. Initialization of Feedback Counters at the Data
Sender . . . . . . . . . . . . . . . . . . . . . . . 15 Sender . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2. The ACE Field . . . . . . . . . . . . . . . . . . . . 16 3.2.2. The ACE Field . . . . . . . . . . . . . . . . . . . . 16
3.2.3. Testing for Zeroing of the ACE Field . . . . . . . . 17 3.2.3. Testing for Zeroing of the ACE Field . . . . . . . . 17
3.2.4. Testing for Mangling of the IP/ECN Field . . . . . . 18 3.2.4. Testing for Mangling of the IP/ECN Field . . . . . . 18
3.2.5. Safety against Ambiguity of the ACE Field . . . . . . 19 3.2.5. Safety against Ambiguity of the ACE Field . . . . . . 19
3.2.6. The AccECN Option . . . . . . . . . . . . . . . . . . 19 3.2.6. The AccECN Option . . . . . . . . . . . . . . . . . . 20
3.2.7. Path Traversal of the AccECN Option . . . . . . . . . 21 3.2.7. Path Traversal of the AccECN Option . . . . . . . . . 21
3.2.8. Usage of the AccECN TCP Option . . . . . . . . . . . 24 3.2.8. Usage of the AccECN TCP Option . . . . . . . . . . . 24
3.3. AccECN Compliance by TCP Proxies, Offload Engines and 3.3. AccECN Compliance by TCP Proxies, Offload Engines and
other Middleboxes . . . . . . . . . . . . . . . . . . . . 26 other Middleboxes . . . . . . . . . . . . . . . . . . . . 26
4. Interaction with Other TCP Variants . . . . . . . . . . . . . 26 4. Interaction with Other TCP Variants . . . . . . . . . . . . . 26
4.1. Compatibility with SYN Cookies . . . . . . . . . . . . . 26 4.1. Compatibility with SYN Cookies . . . . . . . . . . . . . 27
4.2. Compatibility with Other TCP Options and Experiments . . 27 4.2. Compatibility with Other TCP Options and Experiments . . 27
4.3. Compatibility with Feedback Integrity Mechanisms . . . . 27 4.3. Compatibility with Feedback Integrity Mechanisms . . . . 28
5. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 28 5. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 32 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 10.1. Normative References . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Example Algorithms . . . . . . . . . . . . . . . . . 36 Appendix A. Example Algorithms . . . . . . . . . . . . . . . . . 36
A.1. Example Algorithm to Encode/Decode the AccECN Option . . 36 A.1. Example Algorithm to Encode/Decode the AccECN Option . . 36
A.2. Example Algorithm for Safety Against Long Sequences of A.2. Example Algorithm for Safety Against Long Sequences of
ACK Loss . . . . . . . . . . . . . . . . . . . . . . . . 37 ACK Loss . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2.1. Safety Algorithm without the AccECN Option . . . . . 37 A.2.1. Safety Algorithm without the AccECN Option . . . . . 37
A.2.2. Safety Algorithm with the AccECN Option . . . . . . . 39 A.2.2. Safety Algorithm with the AccECN Option . . . . . . . 39
A.3. Example Algorithm to Estimate Marked Bytes from Marked A.3. Example Algorithm to Estimate Marked Bytes from Marked
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 40 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 40
skipping to change at page 3, line 44 skipping to change at page 3, line 44
[RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need
more accurate ECN feedback information whenever more than one marking more accurate ECN feedback information whenever more than one marking
is received in one RTT. A fuller treatment of the motivation for is received in one RTT. A fuller treatment of the motivation for
this specification is given in the associated requirements document this specification is given in the associated requirements document
[RFC7560]. [RFC7560].
This documents specifies an experimental scheme for ECN feedback in This documents specifies an experimental scheme for ECN feedback in
the TCP header to provide more than one feedback signal per RTT. It the TCP header to provide more than one feedback signal per RTT. It
will be called the more accurate ECN feedback scheme, or AccECN for will be called the more accurate ECN feedback scheme, or AccECN for
short. If AccECN progresses from experimental to the standards short. If AccECN progresses from experimental to the standards
track, it is intended to be a complete replacement for classic ECN track, it is intended to be a complete replacement for classic TCP/
feedback, not a fork in the design of TCP. Thus, the applicability ECN feedback, not a fork in the design of TCP. AccECN feedback
of AccECN is intended to include all public and private IP networks complements TCP's loss feedback and it supplements classic TCP/ECN
(and even any non-IP networks over which TCP is used today). Until feedback, so its applicability is intended to include all public and
the AccECN experiment succeeds, [RFC3168] will remain as the private IP networks (and even any non-IP networks over which TCP is
used today), whether or not any nodes on the path support ECN of
whatever flavour.
Until the AccECN experiment succeeds, [RFC3168] will remain as the
standards track specification for adding ECN to TCP. To avoid standards track specification for adding ECN to TCP. To avoid
confusion, in this document we use the term 'classic ECN' for the confusion, in this document we use the term 'classic ECN' for the
pre-existing ECN specification [RFC3168]. pre-existing ECN specification [RFC3168].
AccECN feedback overloads flags and fields in the main TCP header AccECN feedback overloads flags and fields in the main TCP header
with new definitions, so both ends have to support the new wire with new definitions, so both ends have to support the new wire
protocol before it can be used. Therefore during the TCP handshake protocol before it can be used. Therefore during the TCP handshake
the two ends use the three ECN-related flags in the TCP header to the two ends use the three ECN-related flags in the TCP header to
negotiate the most advanced feedback protocol that they can both negotiate the most advanced feedback protocol that they can both
support. support.
skipping to change at page 17, line 6 skipping to change at page 17, line 6
(SYN=0), the Data Receiver MUST encode the three least significant (SYN=0), the Data Receiver MUST encode the three least significant
bits of its r.cep counter into the ACE field it feeds back to the bits of its r.cep counter into the ACE field it feeds back to the
Data Sender. Data Sender.
There is only one exception to this rule: On the final ACK of the There is only one exception to this rule: On the final ACK of the
3WHS, a TCP client (A) in AccECN mode MUST use the ACE field to feed 3WHS, a TCP client (A) in AccECN mode MUST use the ACE field to feed
back which of the 4 possible values of the IP-ECN field were on the back which of the 4 possible values of the IP-ECN field were on the
SYN/ACK (the binary encoding is the same as that used on the SYN/ SYN/ACK (the binary encoding is the same as that used on the SYN/
ACK). Table 3 shows the meaning of each possible value of the ACE ACK). Table 3 shows the meaning of each possible value of the ACE
field on the ACK of the SYN/ACK and the value that an AccECN server field on the ACK of the SYN/ACK and the value that an AccECN server
MUST set s.cep to as a result. MUST set s.cep to as a result. The encoding in Table 3 is solely
applicable on a packet in the client-server direction with an
acknowledgement number 1 greater than the Initial Sequence Number
(ISN) that was used by the server.
+--------------+---------------------------+------------------------+ +--------------+---------------------------+------------------------+
| ACE on ACK | IP-ECN codepoint on | Initial s.cep of | | ACE on ACK | IP-ECN codepoint on | Initial s.cep of |
| of SYN/ACK | SYN/ACK inferred by | server in AccECN mode | | of SYN/ACK | SYN/ACK inferred by | server in AccECN mode |
| | server | | | | server | |
+--------------+---------------------------+------------------------+ +--------------+---------------------------+------------------------+
| 0b000 | {Notes 1, 2} | Disable ECN | | 0b000 | {Notes 1, 2} | Disable ECN |
| 0b001 | {Notes 2, 3} | 5 | | 0b001 | {Notes 2, 3} | 5 |
| 0b010 | Not-ECT | 5 | | 0b010 | Not-ECT | 5 |
| 0b011 | ECT(1) | 5 | | 0b011 | ECT(1) | 5 |
skipping to change at page 18, line 43 skipping to change at page 18, line 47
on arriving packets. on arriving packets.
The value of the ACE field on the last ACK of the 3WHS indicates the The value of the ACE field on the last ACK of the 3WHS indicates the
value of the IP/ECN field when the SYN/ACK arrived at the client. value of the IP/ECN field when the SYN/ACK arrived at the client.
The server can compare this with how it originally set the IP/ECN The server can compare this with how it originally set the IP/ECN
field on the SYN/ACK. If this comparison implies an unsafe field on the SYN/ACK. If this comparison implies an unsafe
transition of the IP/ECN field, for the remainder of the connection transition of the IP/ECN field, for the remainder of the connection
the server MUST NOT send ECN-capable packets, but it MUST continue to the server MUST NOT send ECN-capable packets, but it MUST continue to
feedback any ECN markings on arriving packets. feedback any ECN markings on arriving packets.
The ACK of the SYN/ACK is not reliably delivered (nonetheless, the
count of CE marks is still eventually delivered reliably). If this
ACK does not arrive, the server has to continue to send ECN-capable
packets without having tested for mangling of the IP/ECN field on the
SYN/ACK. Experiments with AccECN deployment will assess whether this
limitation has any effect in practice.
Invalid transitions of the IP/ECN field are defined in [RFC3168] and Invalid transitions of the IP/ECN field are defined in [RFC3168] and
repeated here for convenience: repeated here for convenience:
o the not-ECT codepoint changes; o the not-ECT codepoint changes;
o either ECT codepoint transitions to not-ECT; o either ECT codepoint transitions to not-ECT;
o the CE codepoint changes. o the CE codepoint changes.
RFC 3168 says that a router that changes ECT to not-ECT is invalid RFC 3168 says that a router that changes ECT to not-ECT is invalid
skipping to change at page 24, line 42 skipping to change at page 24, line 49
the safety recommendation in Section 3.2.5 against ambiguity of the safety recommendation in Section 3.2.5 against ambiguity of
the ACE field). the ACE field).
This is stated as a "MUST" so that the data sender can rely on This is stated as a "MUST" so that the data sender can rely on
change-triggered ACKs to detect transitions right from the very change-triggered ACKs to detect transitions right from the very
start of a flow, without first having to detect whether the start of a flow, without first having to detect whether the
receiver complies. A concern has been raised that certain offload receiver complies. A concern has been raised that certain offload
hardware needed for high performance might not be able to support hardware needed for high performance might not be able to support
change-triggered ACKs, although high performance protocols such as change-triggered ACKs, although high performance protocols such as
DCTCP successfully use change-triggered ACKs. One possible DCTCP successfully use change-triggered ACKs. One possible
compromise would be for the receiver to heuristically detect experimental compromise would be for the receiver to heuristically
whether the sender is in slow-start, then to implement change- detect whether the sender is in slow-start, then to implement
triggered ACKs in software while the sender is in slow-start, and change-triggered ACKs in software while the sender is in slow-
offload to hardware otherwise. If the operator disables change- start, and offload to hardware otherwise. If the operator
triggered ACKs, whether partially like this or otherwise, the disables change-triggered ACKs, whether partially like this or
operator will also be responsible for ensuring a co-ordinated otherwise, the operator will also be responsible for ensuring a
sender algorithm is deployed; co-ordinated sender algorithm is deployed;
Continual Repetition: Otherwise, if arriving packets continue to Continual Repetition: Otherwise, if arriving packets continue to
increment the same byte counter, the Data Receiver can include an increment the same byte counter, the Data Receiver can include an
AccECN Option on most or all (delayed) ACKs, but it does not have AccECN Option on most or all (delayed) ACKs, but it does not have
to. If option space is limited on a particular ACK, the Data to. If option space is limited on a particular ACK, the Data
Receiver MUST give precedence to SACK information about loss. It Receiver MUST give precedence to SACK information about loss. It
SHOULD include an AccECN Option if the r.ceb counter has SHOULD include an AccECN Option if the r.ceb counter has
incremented and it MAY include an AccECN Option if r.ec0b or incremented and it MAY include an AccECN Option if r.ec0b or
r.ec1b has incremented; r.ec1b has incremented;
skipping to change at page 32, line 23 skipping to change at page 32, line 31
middlebox. No known way can yet be contrived to take advantage of middlebox. No known way can yet be contrived to take advantage of
this downgrade attack, but it is mentioned here in case someone else this downgrade attack, but it is mentioned here in case someone else
can contrive one. can contrive one.
The AccECN protocol is not believed to introduce any new privacy The AccECN protocol is not believed to introduce any new privacy
concerns, because it merely counts and feeds back signals at the concerns, because it merely counts and feeds back signals at the
transport layer that had already been visible at the IP layer. transport layer that had already been visible at the IP layer.
8. Acknowledgements 8. Acknowledgements
We want to thank Koen De Schepper, Praveen Balasubramanian and We want to thank Koen De Schepper, Praveen Balasubramanian, Michael
Michael Welzl for their input and discussion. The idea of using the Welzl, Gorry Fairhurst, David Black, Spencer Dawkins, Michael Scharf
three ECN-related TCP flags as one field for more accurate TCP-ECN and Michael Tuexen for their input and discussion. The idea of using
feedback was first introduced in the re-ECN protocol that was the the three ECN-related TCP flags as one field for more accurate TCP-
ECN feedback was first introduced in the re-ECN protocol that was the
ancestor of ConEx. ancestor of ConEx.
Bob Briscoe was part-funded by the European Community under its Bob Briscoe was part-funded by the European Community under its
Seventh Framework Programme through the Reducing Internet Transport Seventh Framework Programme through the Reducing Internet Transport
Latency (RITE) project (ICT-317700) and through the Trilogy 2 project Latency (RITE) project (ICT-317700) and through the Trilogy 2 project
(ICT-317756). The views expressed here are solely those of the (ICT-317756). He was also part-funded by the Research Council of
authors. Norway through the TimeIn project. The views expressed here are
solely those of the authors.
This work is partly supported by the European Commission under Mirja Kuehlewind was partly supported by the European Commission
Horizon 2020 grant agreement no. 688421 Measurement and Architecture under Horizon 2020 grant agreement no. 688421 Measurement and
for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat Architecture for a Middleboxed Internet (MAMI), and by the Swiss
for Education, Research, and Innovation under contract no. 15.0268. State Secretariat for Education, Research, and Innovation under
This support does not imply endorsement. contract no. 15.0268. This support does not imply endorsement.
9. Comments Solicited 9. Comments Solicited
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF TCP maintenance and minor modifications working addressed to the IETF TCP maintenance and minor modifications working
group mailing list <tcpm@ietf.org>, and/or to the authors. group mailing list <tcpm@ietf.org>, and/or to the authors.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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,
skipping to change at page 33, line 29 skipping to change at page 33, line 38
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", [RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013, RFC 6994, DOI 10.17487/RFC6994, August 2013,
<https://www.rfc-editor.org/info/rfc6994>. <https://www.rfc-editor.org/info/rfc6994>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-tcpm-alternativebackoff-ecn] [I-D.ietf-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
alternativebackoff-ecn-02 (work in progress), October alternativebackoff-ecn-03 (work in progress), October
2017. 2017.
[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-01 (work in progress), draft-ietf-tcpm-generalized-ecn-02 (work in progress),
September 2017. October 2017.
[I-D.ietf-tsvwg-ecn-experimentation] [I-D.ietf-tsvwg-ecn-experimentation]
Black, D., "Relaxing Restrictions on Explicit Congestion Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn- Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn-
experimentation-07 (work in progress), October 2017. experimentation-07 (work in progress), October 2017.
[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-00 (work in Architecture", draft-ietf-tsvwg-l4s-arch-01 (work in
progress), May 2017. progress), October 2017.
[I-D.kuehlewind-tcpm-ecn-fallback] [I-D.kuehlewind-tcpm-ecn-fallback]
Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path
Probing and Fallback", draft-kuehlewind-tcpm-ecn- Probing and Fallback", draft-kuehlewind-tcpm-ecn-
fallback-01 (work in progress), September 2013. fallback-01 (work in progress), September 2013.
[I-D.moncaster-tcpm-rcv-cheat] [I-D.moncaster-tcpm-rcv-cheat]
Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
Allow Senders to Identify Receiver Non-Compliance", draft- Allow Senders to Identify Receiver Non-Compliance", draft-
moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014. moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.
 End of changes. 21 change blocks. 
42 lines changed or deleted 59 lines changed or added

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