draft-ietf-tcpm-accecn-reqs-06.txt   draft-ietf-tcpm-accecn-reqs-07.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 University of Stuttgart
Intended status: Informational R. Scheffenegger Intended status: Informational R. Scheffenegger
Expires: January 4, 2015 NetApp, Inc. Expires: January 24, 2015 NetApp, Inc.
B. Briscoe B. Briscoe
BT BT
July 3, 2014 July 23, 2014
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-06 draft-ietf-tcpm-accecn-reqs-07
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 4, 2015. This Internet-Draft will expire on January 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
Explicit Congestion Notification (ECN) [RFC3168] is a mechanism where Explicit Congestion Notification (ECN) [RFC3168] is a mechanism where
network nodes can mark IP packets instead of dropping them to network nodes can mark IP packets instead of dropping them to
indicate congestion to the end-points. An ECN-capable receiver will indicate congestion to the end-points. An ECN-capable receiver will
feed this information back to the sender. ECN is specified for TCP feed this information back to the sender. ECN is specified for TCP
in such a way that only one feedback signal can be transmitted per in such a way that only one feedback signal can be transmitted per
Round-Trip Time (RTT). This is sufficient for pre-existing TCP Round-Trip Time (RTT). This is sufficient for pre-existing TCP
congestion control mechanisms that perform only one reduction in congestion control mechanisms that perform only one reduction in
sending rate per RTT, independent of the number of ECN congestion sending rate per RTT, independent of the number of ECN congestion
marks. But recently proposed or deployed mechanisms like Congestion marks. But recently proposed or deployed mechanisms like Congestion
Exposure (ConEx) [RFC6789] or Data Center TCP (DCTCP) [Ali10] need Exposure (ConEx) [RFC6789] or Data Center TCP (DCTCP)
more accurate ECN feedback to work correctly in the case where more [I-D.bensley-tcpm-dctcp] need more accurate ECN feedback than
than one marking is received in any one RTT. 'classic' ECN [RFC3168] to work correctly in the case where more than
one marking is received in any one RTT.
For an in-depth discussion of the application benefits of using ECN
(including with sufficiently granular feedback) see
[I-D.welzl-ecn-benefits].
ECN is also defined for transport protocols beside TCP. ECN feedback ECN is also defined for transport protocols beside TCP. ECN feedback
as defined for RTP/UDP [RFC6679] provides a very detailed level of as defined for RTP/UDP [RFC6679] provides a very detailed level of
information, delivering individual counters for all four ECN information, delivering individual counters for all four ECN
codepoints as well as lost and duplicate segments, but at the cost of codepoints as well as lost and duplicate segments, but at the cost of
high signaling overhead. ECN feedback for SCTP high signaling overhead. ECN feedback for SCTP has been proposed in
[I-D.stewart-tsvwg-sctpecn] delivers a counter for the number of CE [I-D.stewart-tsvwg-sctpecn]. This delivers a counter for the number
marked segments between CWR chunks, but also comes at the cost of of CE marked segments between CWR chunks, but also comes at the cost
increased overhead. of increased overhead.
Today, implementations of DCTCP already exist that alter TCP's ECN Today, implementations of DCTCP already exist that alter TCP's ECN
feedback protocol in proprietary ways (DCTCP was released in feedback protocol in proprietary ways (DCTCP was released in
Microsoft Windows 8, and implementations exist for Linux and Microsoft Windows 8, and implementations exist for Linux and
FreeBSD). The changes DCTCP makes to TCP are not currently the FreeBSD). The changes DCTCP makes to TCP are not currently the
subject of any IETF standardization activity, and they omit subject of any IETF standardization activity, and they omit
capability negotiation, relying instead on uniform configuration capability negotiation, relying instead on uniform configuration
across all hosts and network devices with ECN capability. A primary across all hosts and network devices with ECN capability. A primary
motivation for this document is to intervene before each proprietary motivation for this document is to intervene before each proprietary
implementation invents its own non-interoperable handshake, which implementation invents its own non-interoperable handshake, which
could lead to _de facto_ consumption of the few flags or codepoints could lead to _de facto_ consumption of the few flags or codepoints
that remain available for standardizing capability negotiation. that remain available for standardizing capability negotiation.
This document lists requirements for a robust and interoperable more This document lists requirements for a robust and interoperable TCP/
accurate TCP/ECN feedback protocol that all implementations of new ECN feedback protocol that is more accurate than classic ECN
TCP extensions, like ConEx and/or DCTCP, can use. While a new [RFC3168] and that all implementations of new TCP extensions, like
feedback scheme should still deliver as much information as classic ConEx and/or DCTCP, can use. While a new feedback scheme should
ECN [RFC3168], this document also clarifies what has to be taken into still deliver as much information as classic ECN, this document also
consideration in addition. Thus the listed requirements should be clarifies what has to be taken into consideration in addition. Thus
addressed in the specification of a more accurate ECN feedback the listed requirements should be addressed in the specification of a
scheme. A few solutions have already been proposed. Section 5 more accurate ECN feedback scheme. A few solutions have already been
demonstrates how to use the requirements to compare them, by briefly proposed. Section 5 demonstrates how to use the requirements to
sketching their high level design choices and discussing the benefits compare them, by briefly sketching their high level design choices
and drawbacks of each. and discussing the benefits and drawbacks of each.
The scope of these requirements is not limited to any specific The scope of these requirements is not limited to any specific
environment and is intended for general deployment over public and environment and is intended for general deployment over public and
private IP networks. Candidate solutions should try to adhere to all private IP networks. Candidate solutions should try to adhere to all
these requirements where possible, or document deviations. The these requirements, but where this is not possible they should
ordering of the requirements listed in this document is not to be justify the deviation. The ordering of the requirements listed in
taken as an order of importance, because each requirement might have this document is not to be taken as an order of importance, because
different weight in different deployment scenarios. each requirement might have different weight in different deployment
scenarios.
These requirements are only concerned with the type and quality of These requirements are only concerned with the type and quality of
the ECN feedback signal. The requirements do not stipulate how a TCP the ECN feedback signal. The requirements do not stipulate how a TCP
sender might react to the improved ECN signal. The requirements also sender might react to the improved ECN signal. The requirements also
do not imply that any modifications to TCP senders or receivers are do not imply that any modifications to TCP senders or receivers are
obligatory obligatory.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
We use the following terminology from [RFC3168] and [RFC3540]: We use the following terminology from [RFC3168] and [RFC3540]:
The ECN field in the IP header: The ECN field in the IP header:
Not-ECT: the not ECN-Capable Transport codepoint, Not-ECT: the not ECN-Capable Transport codepoint,
CE: the Congestion Experienced codepoint, CE: the Congestion Experienced codepoint,
ECT(0): the first ECN-Capable Transport codepoint, and ECT(0): the first ECN-Capable Transport codepoint, and
skipping to change at page 4, line 37 skipping to change at page 4, line 36
ECE: the ECN-Echo flag, and ECE: the ECN-Echo flag, and
NS: ECN Nonce Sum. NS: ECN Nonce Sum.
In this document, the ECN feedback scheme as specified in [RFC3168] In this document, the ECN feedback scheme as specified in [RFC3168]
is called 'classic ECN' and any new proposal is called a 'more is called 'classic ECN' and any new proposal is called a 'more
accurate ECN feedback' scheme. A 'congestion mark' is defined as an accurate ECN feedback' scheme. A 'congestion mark' is defined as an
IP packet where the CE codepoint is set. A 'congestion episode' IP packet where the CE codepoint is set. A 'congestion episode'
refers to one or more congestion marks that belong to the same refers to one or more congestion marks that belong to the same
overload situation in the network (usually during one RTT). A TCP overload situation in the network (usually during one RTT). A TCP
segment with the acknowledgment flag set is simply called ACK. segment with the acknowledgment flag set is simply called an ACK.
2. Recap of Classic ECN and ECN Nonce in IP/TCP 2. Recap of Classic ECN and ECN Nonce in IP/TCP
ECN requires two bits in the IP header. The ECN capability of a ECN requires two bits in the IP header. The ECN capability of a
packet is indicated when either one of the two bits is set. A packet is indicated when either one of the two bits is set. A
network node can set both bits simultaneously when it experiences network node can set both bits simultaneously when it experiences
congestion. This leads to the four codepoints (not-ECT, ECT(0), congestion. This leads to the four codepoints (not-ECT, ECT(0),
ECT(1), and CE) as listed above. ECT(1), and CE) as listed above.
In the TCP header the first two bits in byte 14 are defined as ECN In the TCP header the first two bits in byte 14 are defined as ECN
skipping to change at page 6, line 18 skipping to change at page 6, line 18
DCTCP offers very low and predictable queuing delay. DCTCP changes DCTCP offers very low and predictable queuing delay. DCTCP changes
the reaction to congestion of a TCP sender and additionally requires the reaction to congestion of a TCP sender and additionally requires
switches/routers to have ECN enabled and configured with a low step switches/routers to have ECN enabled and configured with a low step
threshold and no signal smoothing, so it is currently only used in threshold and no signal smoothing, so it is currently only used in
private networks, e.g. internal to data centers. DCTCP was released private networks, e.g. internal to data centers. DCTCP was released
in Microsoft Windows 8, and implementations exist for Linux and in Microsoft Windows 8, and implementations exist for Linux and
FreeBSD. To retrieve sufficient congestion information, the FreeBSD. To retrieve sufficient congestion information, the
different DCTCP implementations use a proprietary ECN feedback different DCTCP implementations use a proprietary ECN feedback
protocol, but they omit capability negotiation. Moreover, the protocol, but they omit capability negotiation. Moreover, the
feedback protocol proposed in [Ali10] only works if there are no feedback protocol proposed in [I-D.bensley-tcpm-dctcp] only works if
losses at all, and otherwise it gets very confused (see Appendix A). there are no losses at all, and otherwise it gets very confused (see
Therefore, if a generic more accurate ECN feedback scheme were Appendix A). Therefore, if a generic more accurate ECN feedback
available, it would solve two problems for DCTCP: i) need for a scheme were available, it would solve two problems for DCTCP: i) need
consistent variant of DCTCP to be deployed network-wide and ii) for a consistent variant of DCTCP to be deployed network-wide and ii)
inability to cope with ACK loss. inability to cope with ACK loss.
Classic ECN-TCP would not benefit from more accurate ECN feedback, Classic ECN-TCP would not benefit from more accurate ECN feedback,
but it would not suffer either. The same signal that is currently but it would not suffer either. The same signal that is currently
conveyed with ECN following the specification given in [RFC3168] conveyed with ECN following the specification given in [RFC3168]
would be available. would be available.
The following scenarios should briefly show where accurate ECN The following scenarios should briefly show where accurate ECN
feedback is needed or adds value: feedback is needed or adds value:
skipping to change at page 7, line 49 skipping to change at page 7, line 49
more e.g., due to receive segment coalescing, ACK more e.g., due to receive segment coalescing, ACK
compression, ACK congestion control [RFC5690] or other compression, ACK congestion control [RFC5690] or other
phenomena, see [RFC3449]). In a high congestion situation phenomena, see [RFC3449]). In a high congestion situation
where most of the packets are marked with CE, an accurate where most of the packets are marked with CE, an accurate
feedback mechanism should still be able to signal sufficient feedback mechanism should still be able to signal sufficient
congestion information. Thus the accurate ECN feedback congestion information. Thus the accurate ECN feedback
extension has to take delayed ACKs and ACK loss into account. extension has to take delayed ACKs and ACK loss into account.
Also, a more accurate feedback protocol should still provide Also, a more accurate feedback protocol should still provide
more accurate feedback than classic ECN when delayed ACKs more accurate feedback than classic ECN when delayed ACKs
cover more than two segments, or when a thin stream disables cover more than two segments, or when a thin stream disables
Nagle's algorithm. Finally, the feedback mechanism should Nagle's algorithm [RFC0896]. Finally, the feedback mechanism
not be impacted by reordering of ACKs, even when the ACK'ed should not be impacted by reordering of ACKs, even when the
sequence number does not increase. ACK'ed sequence number does not increase.
Timeliness Timeliness
A CE mark can be induced by the sending host, or more A CE mark can be induced by the sending host, or more
commonly a network node on the transmission path, and is then commonly a network node on the transmission path, and is then
echoed by the receiver in the TCP ACK. Thus when this echoed by the receiver in the TCP ACK. Thus when this
information arrives at the sender, it is naturally already information arrives at the sender, it is naturally already
about one RTT old. With a sufficient ACK rate a further about one RTT old. With a sufficient ACK rate a further
delay of a small number of packets can be tolerated. delay of a small number of packets can be tolerated.
However, this information will become stale with large However, this information will become stale with large
delays, given the dynamic nature of networks. TCP congestion delays, given the dynamic nature of networks. TCP congestion
skipping to change at page 8, line 26 skipping to change at page 8, line 26
congestion feedback information should be delivered within congestion feedback information should be delivered within
about one RTT. about one RTT.
Integrity Integrity
The integrity of the feedback in a more accurate ECN feedback The integrity of the feedback in a more accurate ECN feedback
scheme should be assured, at least as well as the ECN Nonce. scheme should be assured, at least as well as the ECN Nonce.
Alternatively, it should at least be possible to give strong Alternatively, it should at least be possible to give strong
incentives for the receiver and network nodes to cooperate incentives for the receiver and network nodes to cooperate
honestly. honestly.
Given there are known problems with the ECN Nonce (as Given there are known problems with ECN Nonce deployment,
identified above), this document only requires that the this document only requires that the integrity of the more
integrity of the more accurate ECN feedback can be assured as accurate ECN feedback can be assured; it does not require
an inherent part of the new more accurate ECN feedback that the ECN Nonce mechanism is employed to achieve this.
protocol; it does not require that the ECN Nonce mechanism is Indeed, if integrity could be provided else-wise, a more
employed to achieve this. Indeed, if integrity could be accurate ECN feedback protocol might re-purpose the nonce sum
provided else-wise, a more accurate ECN feedback protocol (NS) flag in the TCP header.
might re-purpose the nonce sum (NS) flag in the TCP header.
If the more accurate ECN feedback scheme provides sufficient If the more accurate ECN feedback scheme provides sufficient
information, the integrity check could e.g. be performed by information, the integrity check could e.g. be performed by
deterministically setting the CE in the sender and monitoring deterministically setting the CE in the sender and monitoring
the respective feedback (similar to ECT(1) and the ECN Nonce the respective feedback (similar to ECT(1) and the ECN Nonce
sum). Whether a sender should enforce when it detects wrong sum). Whether a sender should enforce when it detects wrong
feedback information, and what kind of enforcement it should feedback information, and what kind of enforcement it should
apply, are policy issues that need not be specified as part apply, are policy issues that need not be specified as part
of more accurate ECN feedback signal scheme itself, but of more accurate ECN feedback signal scheme itself, but
rather when specifying an update to core TCP mechanisms like rather when specifying an update to core TCP mechanisms like
skipping to change at page 10, line 43 skipping to change at page 10, line 42
simply ignore the excess information. simply ignore the excess information.
Furthermore, the receiver should not make assumptions about the Furthermore, the receiver should not make assumptions about the
mechanism that was used to set the markings nor about any mechanism that was used to set the markings nor about any
interpretation or reaction to the congestion signal. The receiver interpretation or reaction to the congestion signal. The receiver
only needs to faithfully reflect congestion information back to the only needs to faithfully reflect congestion information back to the
sender. sender.
5. Design Approaches 5. Design Approaches
This section introduces some possible TCP ECN feedback design
approaches. The purpose of this section is to give examples of how
trade-offs might be needed between the requirements, as input to
future IETF work to specify a protocol. The order is not significant
and there is no intention to endorse any particular approach.
All approaches presented below (and proposed so far) are able to All approaches presented below (and proposed so far) are able to
provide accurate ECN feedback information as long as no ACK loss provide accurate ECN feedback information as long as no ACK loss
occurs and the congestion rate is reasonable. In the case of a high occurs and the congestion rate is reasonable. In the case of a high
ACK loss rate or very high congestion (CE marking) rate, the proposed ACK loss rate or very high congestion (CE marking) rate, the proposed
schemes have different resilience characteristics depending on the schemes have different resilience characteristics depending on the
number of bits used for the encoding. While classic ECN provides number of bits used for the encoding. While classic ECN provides
reliable (but inaccurate) feedback of a maximum of one congestion reliable (but inaccurate) feedback of a maximum of one congestion
signal per RTT, the proposed schemes do not implement an explicit signal per RTT, the proposed schemes do not implement an explicit
acknowledgement mechanism for the feedback (as e.g. the ECE / CWR acknowledgement mechanism for the feedback (as e.g. the ECE / CWR
exchange of [RFC3168]). exchange of [RFC3168]).
skipping to change at page 11, line 27 skipping to change at page 11, line 31
loss of ACK, particularly pure ACKs (no payload and therefore loss of ACK, particularly pure ACKs (no payload and therefore
delivered unreliably). delivered unreliably).
A couple of schemes have been proposed so far: A couple of schemes have been proposed so far:
o A naive one-bit scheme that sends one ECE for each CE received o A naive one-bit scheme that sends one ECE for each CE received
could use CWR to increase robustness against ACK loss by could use CWR to increase robustness against ACK loss by
introducing redundant information on the next ACK, but this is introducing redundant information on the next ACK, but this is
still vulnerable to ACK loss. still vulnerable to ACK loss.
o The scheme defined for DCTCP [Ali10], which toggles the ECE o The scheme defined for DCTCP [I-D.bensley-tcpm-dctcp], which
feedback on an immediate ACK whenever the CE marking changes, and toggles the ECE feedback on an immediate ACK whenever the CE
otherwise feeds back delayed ACKs with the ECE value unchanged. marking changes, and otherwise feeds back delayed ACKs with the
Appendix A demonstrates that this scheme is still ambiguous to the ECE value unchanged. Appendix A demonstrates that this scheme is
sender if the ACKs are pure ACKs, and if some may have been lost. still ambiguous to the sender if the ACKs are pure ACKs, and if
some may have been lost.
Alternatively, the receiver uses the three ECN/NS header flags, ECE, Alternatively, the receiver uses the three ECN/NS header flags, ECE,
CWR and NS to represent a counter that signals the accumulated number CWR and NS to represent a counter that signals the accumulated number
of CE markings it has received. Resilience against loss is better of CE markings it has received. Resilience against loss is better
than the flag-based schemes, but may not suffice in the presence of than the flag-based schemes, but may not suffice in the presence of
extended ACK loss that otherwise would not affect the TCP sender's extended ACK loss that otherwise would not affect the TCP sender's
performance. performance.
A number of coding schemes have been proposed so far in this A number of coding schemes have been proposed so far in this
category: category:
skipping to change at page 12, line 36 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. cleared. 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 28 skipping to change at page 13, line 35
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). The views expressed here are solely those of the
authors. authors.
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 should 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
on-path - i.e. the normal TCP acceptance techniques have to be used genuinely part of the flow and not spoofed - i.e. the normal TCP
to verify the packet was part of the flow before returning any acceptance techniques have to be used to verify that the segment is
contained ECN information, and similarly ECN feedback is only part of the flow before returning any contained ECN information, and
accepted on valid ACKs. similarly ECN feedback is only accepted on valid ACKs.
Given ECN feedback is used as input for congestion control, the Given ECN feedback is used as input for congestion control, the
respective algorithm would not react appropriately if ECN feedback respective algorithm would not react appropriately if ECN feedback
were lost and the resilience mechanism to recover it was inadequate. were lost and the resilience mechanism to recover it was inadequate.
This resilience requirement is articulated in Section 4. However, it This resilience requirement is articulated in Section 4. However, it
should be noted that ECN feedback is not the last resort against should be noted that ECN feedback is not the last resort against
congestion collapse, because if there is insufficient response to congestion collapse, because if there is insufficient response to
ECN, loss will ensue, and TCP will still react appropriately to loss. ECN, loss will ensue, and TCP will still react appropriately to loss.
A receiver could suppress ECN feedback information leading to its A receiver could suppress ECN feedback information leading to its
connections consuming excess sender or network resources. This connections consuming excess sender or network resources. This
problem is similar to that seen with the classic ECN feedback scheme problem is similar to that seen with the classic ECN feedback scheme
and should be addressed by integrity checking as required in and should be addressed by integrity checking as required in
Section 4. Section 4.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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", RFC of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001. 3168, September 2001.
[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
[Ali10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, [I-D.bensley-tcpm-dctcp]
P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data sbens@microsoft.com, s., Eggert, L., and D. Thaler,
Center TCP (DCTCP)", ACM SIGCOMM CCR 40(4)63-74, October "Microsoft's Datacenter TCP (DCTCP): TCP Congestion
2010, <http://portal.acm.org/citation.cfm?id=1851192>. Control for Datacenters", draft-bensley-tcpm-dctcp-01
(work in progress), June 2014.
[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-02 (work in progress), November moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.
2007.
[I-D.stewart-tsvwg-sctpecn] [I-D.stewart-tsvwg-sctpecn]
Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream
Control Transmission Protocol (SCTP)", draft-stewart- Control Transmission Protocol (SCTP)", draft-stewart-
tsvwg-sctpecn-05 (work in progress), January 2014. tsvwg-sctpecn-05 (work in progress), January 2014.
[I-D.welzl-ecn-benefits]
Welzl, M. and G. Fairhurst, "The Benefits to Applications
of using Explicit Congestion Notification (ECN)", draft-
welzl-ecn-benefits-01 (work in progress), July 2014.
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, December 2002. Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
skipping to change at page 15, line 18 skipping to change at page 15, line 25
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, August 2012. for RTP over UDP", RFC 6679, August 2012.
[RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion
Exposure (ConEx) Concepts and Use Cases", RFC 6789, Exposure (ConEx) Concepts and Use Cases", RFC 6789,
December 2012. December 2012.
Appendix A. Ambiguity of the More Accurate ECN Feedback in DCTCP Appendix A. Ambiguity of the More Accurate ECN Feedback in DCTCP
As defined in [Ali10], a DCTCP receiver feeds back ECE=0 on delayed As defined in [I-D.bensley-tcpm-dctcp], a DCTCP receiver feeds back
ACKs as long as CE remains 0, and also immediately sends an ACK with ECE=0 on delayed ACKs as long as CE remains 0, and also immediately
ECE=0 when CE transitions to 1. Similarly, it continually feeds back sends an ACK with ECE=0 when CE transitions to 1. Similarly, it
ECE=1 on delayed ACKs while CE remains 1 and immediately feeds back continually feeds back ECE=1 on delayed ACKs while CE remains 1 and
ECE=1 when CE transitions to 0. A sender can unambiguously decode immediately feeds back ECE=1 when CE transitions to 0. A sender can
this scheme if there is never any ACK loss, and the sender assumes unambiguously decode this scheme if there is never any ACK loss, and
there will never be any ACK loss. the sender assumes there will never be any ACK loss.
The following two examples show that the feedback sequence becomes The following two examples show that the feedback sequence becomes
highly ambiguous to the sender, if either of these conditions is highly ambiguous to the sender, if either of these conditions is
broken. Below, '0' will represent ECE=0, '1' will represent ECE=1 broken. Below, '0' will represent ECE=0, '1' will represent ECE=1
and '.' will represent a gap of one segment between delayed ACKs. and '.' will represent a gap of one segment between delayed ACKs.
Now imagine that the sender receives the following sequence of Now imagine that the sender receives the following sequence of
feedback on 3 pure ACKs: feedback on 3 pure ACKs:
0.0.0 0.0.0
 End of changes. 24 change blocks. 
75 lines changed or deleted 89 lines changed or added

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