draft-ietf-tcpm-accecn-reqs-07.txt   draft-ietf-tcpm-accecn-reqs-08.txt 
TCP Maintenance and Minor Extensions (tcpm) M. Kuehlewind, Ed. TCP Maintenance and Minor Extensions (tcpm) M. Kuehlewind, Ed.
Internet-Draft University of Stuttgart Internet-Draft ETH Zurich
Intended status: Informational R. Scheffenegger Intended status: Informational R. Scheffenegger
Expires: January 24, 2015 NetApp, Inc. Expires: September 10, 2015 NetApp, Inc.
B. Briscoe B. Briscoe
BT BT
July 23, 2014 March 9, 2015
Problem Statement and Requirements for a More Accurate ECN Feedback Problem Statement and Requirements for a More Accurate ECN Feedback
draft-ietf-tcpm-accecn-reqs-07 draft-ietf-tcpm-accecn-reqs-08
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
congestion to the end-points. An ECN-capable receiver will feed this congestion to the end-points. An ECN-capable receiver will feed this
information back to the sender. ECN is specified for TCP in such a information back to the sender. ECN is specified for TCP in such a
way that it can only feed back one congestion signal per Round-Trip way that it can only feed back one congestion signal per Round-Trip
Time (RTT). In contrast, ECN for other transport protocols, such as Time (RTT). In contrast, ECN for other transport protocols, such as
RTP/UDP and SCTP, is specified with more accurate ECN feedback. RTP/UDP and SCTP, is specified with more accurate ECN feedback.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 24, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 12, line 43 skipping to change at page 12, line 43
Alternatively, a new method could standardise the use of the bits in Alternatively, a new method could standardise the use of the bits in
the Urgent Pointer field (see [RFC6093]) to signal more bits of its the Urgent Pointer field (see [RFC6093]) to signal more bits of its
congestion signal counter, but only whenever it does not set the congestion signal counter, but only whenever it does not set the
Urgent Flag. As this is often the case, resilience could be Urgent Flag. As this is often the case, resilience could be
increased without additional header overhead. increased without additional header overhead.
Any proposal to use such bits would need to check the likelihood that Any proposal to use such bits would need to check the likelihood that
some middleboxes might discard or 'normalize' the currently unused some middleboxes might discard or 'normalize' the currently unused
flag bits or a non-zero Urgent Pointer when the Urgent Flag is flag bits or a non-zero Urgent Pointer when the Urgent Flag is
cleared. Assignment of any of these bits would then require an IETF cleared. If during experimentation certain bits have been proven to
standards action. be usable, the assignment of any of these bits would then require an
IETF standards action.
5.3. Using a TCP Option 5.3. Using a TCP Option
Alternatively, a new TCP option could be introduced, to help maintain Alternatively, a new TCP option could be introduced, to help maintain
the accuracy and integrity of ECN feedback between receiver and the accuracy and integrity of ECN feedback between receiver and
sender. Such an option could provide higher resilience and even more sender. Such an option could provide higher resilience and even more
information, perhaps as much as ECN for RTP/UDP [RFC6679], which information, perhaps as much as ECN for RTP/UDP [RFC6679], which
explicitly provides the number of ECT(0), ECT(1), CE, non-ECT marked explicitly provides the number of ECT(0), ECT(1), CE, non-ECT marked
and lost packets, or as much as a proposal for SCTP that counts the and lost packets, or as much as a proposal for SCTP that counts the
number of ECN marks [I-D.stewart-tsvwg-sctpecn] between CWR chunks. number of ECN marks [I-D.stewart-tsvwg-sctpecn] between CWR chunks.
skipping to change at page 13, line 26 skipping to change at page 13, line 27
6. Acknowledgements 6. Acknowledgements
Thanks to Gorry Fairhurst for his review and for ideas on CE-based Thanks to Gorry Fairhurst for his review and for ideas on CE-based
integrity checking and to Mohammad Alizadeh for suggesting the need integrity checking and to Mohammad Alizadeh for suggesting the need
to avoid bias. to avoid bias.
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 views expressed here are solely those of the
authors. authors, in the context of the mentioned funding projects
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
ECN feedback information must only be used if the other information ECN feedback information must only be used if the other information
contained in a received TCP segment indicates that the congestion was contained in a received TCP segment indicates that the congestion was
genuinely part of the flow and not spoofed - i.e. the normal TCP genuinely part of the flow and not spoofed - i.e. the normal TCP
skipping to change at page 14, line 25 skipping to change at page 14, line 28
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC Congestion Notification (ECN) Signaling with Nonces", RFC
3540, June 2003. 3540, June 2003.
9.2. Informative References 9.2. Informative References
[I-D.bensley-tcpm-dctcp] [I-D.bensley-tcpm-dctcp]
sbens@microsoft.com, s., Eggert, L., and D. Thaler, sbens@microsoft.com, s., Eggert, L., and D. Thaler,
"Microsoft's Datacenter TCP (DCTCP): TCP Congestion "Microsoft's Datacenter TCP (DCTCP): TCP Congestion
Control for Datacenters", draft-bensley-tcpm-dctcp-01 Control for Datacenters", draft-bensley-tcpm-dctcp-02
(work in progress), June 2014. (work in progress), January 2015.
[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.
[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.
skipping to change at page 16, line 20 skipping to change at page 16, line 24
Sequences with a longer gap (e.g. 0...0.0) become far more ambiguous. Sequences with a longer gap (e.g. 0...0.0) become far more ambiguous.
It helps a little if the sender knows the distance the receiver uses It helps a little if the sender knows the distance the receiver uses
between delayed ACKs, and it helps a lot if the distance is 1, i.e. between delayed ACKs, and it helps a lot if the distance is 1, i.e.
no delayed ACKs, but even then there will still be ambiguity whenever no delayed ACKs, but even then there will still be ambiguity whenever
there are pure ACK losses. there are pure ACK losses.
Authors' Addresses Authors' Addresses
Mirja Kuehlewind (editor) Mirja Kuehlewind (editor)
University of Stuttgart ETH Zurich
Pfaffenwaldring 47 Gloriastrasse 35
Stuttgart 70569 Zurich 8092
Germany Switzerland
Email: mirja.kuehlewind@ikr.uni-stuttgart.de Email: mirja.kuehlewind@tik.ee.ethz.ch
Richard Scheffenegger Richard Scheffenegger
NetApp, Inc. NetApp, Inc.
Am Euro Platz 2 Am Euro Platz 2
Vienna 1120 Vienna 1120
Austria Austria
Phone: +43 1 3676811 3146 Phone: +43 1 3676811 3146
Email: rs@netapp.com Email: rs@netapp.com
 End of changes. 11 change blocks. 
17 lines changed or deleted 18 lines changed or added

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