GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7560

Internet Engineering Task Force (IETF) M. Kuehlewind, Ed. Request for Comments: 7560 ETH Zurich Category: Informational R. Scheffenegger ISSN: 2070-1721 NetApp, Inc.

                                                            B. Briscoe
                                                                    BT
                                                           August 2015
     Problem Statement and Requirements for Increased Accuracy
         in Explicit Congestion Notification (ECN) Feedback

Abstract

 Explicit Congestion Notification (ECN) is a mechanism where network
 nodes can mark IP packets, instead of dropping them, to indicate
 congestion to the endpoints.  An ECN-capable receiver will feed this
 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
 Time (RTT).  In contrast, ECN for other transport protocols, such as
 RTP/UDP and SCTP, is specified with more accurate ECN feedback.
 Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data
 Center TCP (DCTCP)) need more accurate ECN feedback in the case where
 more than one marking is received in one RTT.  This document
 specifies requirements for an update to the TCP protocol to provide
 more accurate ECN feedback.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7560.

Kuehlewind, et al. Informational [Page 1] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

Copyright Notice

 Copyright (c) 2015 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
 2.  Recap of Classic ECN and ECN Nonce in IP/TCP  . . . . . . . .   5
 3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
 4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   8
 5.  Design Approaches . . . . . . . . . . . . . . . . . . . . . .  11
   5.1.  Redefinition of ECN/NS Header Bits  . . . . . . . . . . .  11
   5.2.  Using Other Header Bits . . . . . . . . . . . . . . . . .  13
   5.3.  Using a TCP Option  . . . . . . . . . . . . . . . . . . .  13
 6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
 7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
   7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
 Appendix A.  Ambiguity of the More Accurate ECN Feedback in DCTCP  16
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Kuehlewind, et al. Informational [Page 2] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

1. Introduction

 Explicit Congestion Notification (ECN) [RFC3168] is a mechanism where
 network nodes can mark IP packets instead of dropping them to
 indicate congestion to the endpoints.  An ECN-capable receiver will
 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
 Round-Trip Time (RTT).  This is sufficient for preexisting TCP
 congestion control mechanisms that perform only one reduction in
 sending rate per RTT, independent of the number of ECN congestion
 marks.  But recently proposed or deployed mechanisms like Congestion
 Exposure (ConEx) [RFC6789] or Data Center TCP (DCTCP) [DCTCP] need
 more accurate ECN feedback than '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 [ECN-BENEFITS].
 ECN is also defined for transport protocols beside TCP.  ECN feedback
 as defined for RTP/UDP [RFC6679] provides a very detailed level of
 information, delivering individual counters for all four ECN
 codepoints as well as lost and duplicate segments, but at the cost of
 high signalling overhead.  ECN feedback for SCTP has been proposed in
 [SCTP-ECN].  This delivers a counter for the number of ECN-capable
 packets that were marked due to congestion (since the last sender-
 side window reduction), but it comes at the cost of increased
 overhead.
 Today, implementations of DCTCP already exist that alter TCP's ECN
 feedback protocol in proprietary ways (DCTCP was released in
 Microsoft Windows 8, and implementations exist for Linux and
 FreeBSD).  However, the changes DCTCP makes to TCP omit capability
 negotiation, relying instead on uniform configuration across all
 hosts and network devices with ECN capability.  A primary motivation
 for this document is to intervene before each proprietary
 implementation invents its own non-interoperable handshake, which
 could lead to _de facto_ consumption of the few flags or codepoints
 that remain available for standardizing capability negotiation.
 This document lists requirements for a robust and interoperable TCP/
 ECN feedback protocol that is more accurate than classic ECN
 [RFC3168] and that all implementations of new TCP extensions, like
 ConEx and/or DCTCP, can use.  While a new feedback scheme should
 still deliver as much information as classic ECN, this document also
 clarifies what has to be taken into consideration in addition.  Thus,
 the listed requirements should be addressed in the specification of a
 more accurate ECN feedback scheme.  A few solutions have already been

Kuehlewind, et al. Informational [Page 3] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

 proposed.  Section 5 demonstrates how to use the requirements to
 compare them, by briefly sketching their high-level design choices
 and discussing the benefits and drawbacks of each.
 The scope of these requirements is not limited to any specific
 environment and is intended for general deployment over public and
 private IP networks.  Candidate solutions should try to adhere to all
 these requirements, but, where this is not possible, they should
 justify the deviation.  The ordering of the requirements listed in
 this document is not to be taken as an order of importance, because
 each requirement might have different weight in different deployment
 scenarios.
 These requirements are only concerned with the type and quality of
 the ECN feedback signal.  The requirements do not stipulate how a TCP
 sender might react to the improved ECN signal.  The requirements also
 do not imply that any modifications to TCP senders or receivers are
 obligatory.

1.1. Terminology

 We use the following terminology from [RFC3168] and [RFC3540]:
 The ECN field in the IP header:
    Not-ECT: the not ECN-Capable Transport codepoint,
    CE:      the Congestion Experienced codepoint,
    ECT(0):  the first ECN-Capable Transport codepoint, and
    ECT(1):  the second ECN-Capable Transport codepoint.
 The ECN flags in the TCP header:
    CWR:     the Congestion Window Reduced flag,
    ECE:     the ECN-Echo flag, and
    NS:      ECN Nonce Sum.
 In this document, the ECN feedback scheme as specified in [RFC3168]
 is called 'classic ECN' and any new proposal is called a 'more
 accurate ECN feedback' scheme.  A 'congestion mark' is defined as an
 IP packet where the CE codepoint is set.  A 'congestion episode'
 refers to one or more congestion marks that belong to the same
 overload situation in the network (usually during one RTT).  A TCP
 segment with the acknowledgement flag set is simply called an ACK.

Kuehlewind, et al. Informational [Page 4] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

2. Recap of Classic ECN and ECN Nonce in IP/TCP

 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
 network node can set both bits simultaneously when it experiences
 congestion.  This leads to the four codepoints (Not-ECT, ECT(0),
 ECT(1), and CE) as listed above.
 In the TCP header, the first two bits in byte 14 are defined as ECN
 feedback for each half-connection.  A TCP receiver signals the
 reception of a congestion mark using the ECN-Echo (ECE) flag in the
 TCP header.  For reliability, the receiver continues to set the ECE
 flag on every ACK.  To enable the TCP receiver to determine when to
 stop setting the ECE flag, the sender sets the CWR flag upon
 reception of an ECE feedback signal.  This always leads to a full RTT
 of ACKs with ECE set.  Thus, the receiver cannot signal back any
 additional CE markings arriving within the same RTT.
 The ECN Nonce [RFC3540] is an experimental addition to ECN that the
 TCP sender can use to protect itself against accidental or malicious
 concealment of CE-marked or dropped packets.  This addition defines
 the last bit of byte 13 in the TCP header as the Nonce Sum (NS) flag.
 The receiver maintains a nonce sum that counts the occurrence of
 ECT(1) packets and signals the least significant bit of this sum on
 the NS flag.  There are no known deployments of a TCP stack that
 makes use of the ECN Nonce extension.
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               |           | N | C | E | U | A | P | R | S | F |
   | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
   |               |           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   Figure 1: The (Post-ECN Nonce) Definition of the TCP Header Flags
 An alternative for a sender to assure feedback integrity has been
 proposed where the sender itself occasionally inserts a CE mark or
 reorders packets, and checks that the receiver feeds these back
 faithfully [TEST-RCV].  This alternative consumes no header bits or
 codepoints, and it releases the ECT(1) codepoint in the IP header and
 the NS flag in the TCP header for other uses.

Kuehlewind, et al. Informational [Page 5] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

3. Use Cases

 The following two examples serve to show where existing mechanisms
 would already benefit from more accurate ECN feedback information.
 However, as it is hard to predict the future, once a more accurate
 ECN feedback mechanism that adheres to the requirements stated in
 this document is widely deployed, it's very likely that additional
 uses will be found.  The examples listed below are in no particular
 order.
 ConEx is an experimental approach that allows a sender to relay
 congestion feedback provided by the receiver into the network along
 the forward data path.  ConEx information can be used for traffic
 management to limit traffic proportionate to the actual congestion
 being caused, rather than limiting traffic based on rate or volume
 [RFC6789].  A ConEx sender uses selective acknowledgements (SACK)
 [RFC2018] for accurate feedback of loss signals, but until now TCP
 has offered no equivalent accurate feedback for ECN.
 DCTCP offers very low and predictable queuing delay.  DCTCP changes
 the reaction to congestion of a TCP sender and additionally requires
 switches/routers to have ECN enabled and configured with a low step
 threshold and no signal smoothing, so it is currently only used in
 private networks, e.g., internal to data centers.  DCTCP was released
 in Microsoft Windows 8, and implementations exist for Linux and
 FreeBSD.  To retrieve sufficient congestion information, the
 different DCTCP implementations use a proprietary ECN feedback
 protocol, but they omit capability negotiation.  Moreover, the
 feedback protocol proposed in [DCTCP] only works if there are no
 losses at all, and otherwise it gets very confused (see Appendix A).
 Therefore, if a generic, more accurate ECN feedback scheme were
 available, it would solve two problems for DCTCP: i) the need for a
 consistent variant of DCTCP to be deployed network-wide and ii) the
 inability to cope with ACK loss.
 Classic ECN-TCP would not benefit from more accurate ECN feedback,
 but it would not suffer either.  The same signal that is currently
 conveyed with ECN following the specification given in [RFC3168]
 would be available.

Kuehlewind, et al. Informational [Page 6] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

 The following scenarios should briefly show where accurate ECN
 feedback is needed or adds value:
 A sender with standardized TCP congestion control that supports
 ConEx:
    In this case, the ConEx mechanism uses the extra information per
    RTT to re-echo the precise congestion information, but the
    congestion control algorithm still ignores multiple marks per RTT
    [RFC5681].
 A sender using DCTCP congestion control without ConEx:
    The congestion control algorithm uses the extra info per RTT to
    perform its decrease depending on the number of congestion marks.
 A sender using DCTCP congestion control and supporting ConEx:
    Both the congestion control algorithm and ConEx use the more
    accurate ECN feedback mechanism.
 As-yet-unspecified sender mechanisms:
    The above are two examples of more general interest in sender
    mechanisms that respond to the extent of congestion feedback, not
    just its existence.  It will greatly simplify incremental
    deployment if the sender can unilaterally deploy new behaviours
    and rely on the presence of generic receivers that have already
    implemented more accurate feedback.
 A TCP sender using congestion control as specified in RFC 5681
 without ConEx:
    No accurate feedback is necessary here.  The congestion control
    algorithm still reacts to only one signal per RTT.  But, it is
    best to feed back all the information the receiver gets, whether
    or not the sender uses it -- at least as long as overhead is low
    or zero.
 Using CE for checking integrity:
    If a more accurate ECN feedback scheme feeds all occurrences of CE
    marks back, a sender could perform integrity checking by
    occasionally injecting CE marks itself.  Specifically, a sender
    can send packets that it randomly marks with CE (at low
    frequency), then check if feedback is received for these packets.
    The congestion notification feedback for these self-injected
    markings would not require a congestion control reaction
    [TEST-RCV].

Kuehlewind, et al. Informational [Page 7] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

4. Requirements

 The requirements of the accurate ECN feedback protocol are to have
 fairly accurate (not necessarily perfect), timely, and protected
 signalling.  This leads to the following requirements, which should
 be discussed for any proposed more accurate ECN feedback scheme:
 Resilience
    The ECN feedback signal is carried within the ACK.  Pure TCP ACKs
    can get lost without recovery (not just due to congestion but also
    due to deliberate ACK thinning).  Moreover, delayed ACKs are
    commonly used with TCP.  Typically, an ACK is triggered after two
    data segments (or more, e.g., due to receive segment coalescing,
    ACK compression, ACK congestion control [RFC5690], or other
    phenomena; see [RFC3449]).  In a high-congestion situation where
    most of the packets are marked with CE, an accurate feedback
    mechanism should still be able to signal sufficient congestion
    information.  Thus, the accurate ECN feedback extension has to
    take delayed ACKs and ACK loss into account.  Also, a more
    accurate feedback protocol should still provide more accurate
    feedback than classic ECN when delayed ACKs cover more than two
    segments, or when a thin stream disables Nagle's algorithm
    [RFC896].  Finally, the feedback mechanism should not be impacted
    by reordering of ACKs, even when the ACKed sequence number does
    not increase.
 Timeliness
    A CE mark can be induced by the sending host, or more commonly a
    network node on the transmission path, and is then echoed by the
    receiver in the TCP ACK.  Thus, when this information arrives at
    the sender, it is naturally already about one RTT old.  With a
    sufficient ACK rate, a further delay of a small number of packets
    can be tolerated.  However, this information will become stale
    with large delays, given the dynamic nature of networks.  TCP
    congestion control (which itself partly introduces these dynamics)
    operates on a time scale of one RTT.  Thus, to be timely,
    congestion feedback information should be delivered within about
    one RTT.
 Integrity
    The integrity of the feedback in a more accurate ECN feedback
    scheme should be assured, at least as well as the ECN Nonce.
    Alternatively, it should at least be possible to give strong
    incentives for the receiver and network nodes to cooperate
    honestly.

Kuehlewind, et al. Informational [Page 8] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

    Given there are known problems with ECN Nonce deployment, this
    document only requires that the integrity of the more accurate ECN
    feedback can be assured; it does not require that the ECN Nonce
    mechanism is employed to achieve this.  Indeed, if integrity could
    be provided in another manner, a more accurate ECN feedback
    protocol might repurpose the nonce sum (NS) flag in the TCP
    header.
    If the more accurate ECN feedback scheme provides sufficient
    information, the integrity check could be performed by, e.g.,
    deterministically setting the CE in the sender and monitoring the
    respective feedback (similar to ECT(1) and the ECN Nonce sum).
    Whether a sender should enforce when it detects wrong feedback
    information, and what kind of enforcement it should apply, are
    policy issues that need not be specified as part of the more
    accurate ECN feedback signal scheme itself, but rather when
    specifying an update to core TCP mechanisms like congestion
    control that make use of the more accurate ECN signal.
 Accuracy
    Classic ECN feeds back one congestion notification per RTT; this
    is sufficient for classic TCP congestion control, which reduces
    the sending rate at most once per RTT.  Thus, the more accurate
    ECN feedback scheme should ensure that, if a congestion episode
    occurs, at least one congestion notification is echoed and
    received per RTT as classic ECN would do.  Of course, the goal of
    a more accurate ECN extension is to reconstruct the number of CE
    markings more accurately.  In the best case, the new scheme should
    even allow reconstruction of the exact number of payload bytes
    that a CE-marked packet was carrying.  However, it is accepted
    that it may be too complex for a sender to get the exact number of
    congestion markings or marked bytes in all situations.  Ideally,
    the feedback scheme should preserve the order in which any (of the
    four) ECN signals were received.  And, ideally, it would even be
    possible for the sender to determine which of the packets covered
    by one delayed ACK were congestion marked, e.g., if the flow
    consists of packets of different sizes, or to allow for future
    protocols where the order of the markings may be important.
    In the best case, a sender that sees more accurate ECN feedback
    information would be able to reconstruct the occurrence of any of
    the four codepoints (Not-ECT, CE, ECT(0), ECT(1)).  However,
    assuming the sender marks all data packets as ECN-capable and uses
    a default setting of ECT(0) (as with [RFC3168]), solely feeding
    back the occurrence of CE and ECT(1) might be sufficient.  Because
    the sender can keep account of the transmitted segments with any
    of the three ECN codepoints, conveying any two of these back to
    the sender is sufficient for it to reconstruct the third as

Kuehlewind, et al. Informational [Page 9] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

    observed by the receiver.  Thus, a more accurate ECN feedback
    scheme should at least provide information on two of these
    signals, e.g., CE and ECT(1).
    If a more accurate ECN scheme can reliably deliver feedback in
    most but not all circumstances, ideally the scheme should at least
    not introduce bias.  In other words, undetected loss of some ACKs
    should be as likely to increase as decrease the sender's estimate
    of the probability of ECN marking.
 Complexity
    Implementation should be as simple as possible, and only a minimum
    of additional state information should be needed.  This will
    enable more accurate ECN feedback to be used as the default
    feedback mechanism, even if only one ECN feedback signal per RTT
    is needed.
 Overhead
    A more accurate ECN feedback signal should limit the additional
    network load, because ECN feedback is ultimately not critical
    information (in the worst case, loss will still be available as a
    congestion signal of last resort).  As feedback information has to
    be provided frequently and in a timely fashion, potentially all or
    a large fraction of TCP acknowledgements might carry this
    information.  Ideally, no additional segments should be exchanged
    compared to a TCP session as specified in RFC 3168, and the
    overhead in each segment should be minimized.
 Backward and forward compatibility
    Given more accurate ECN feedback will involve a change to the TCP
    protocol, it should be negotiated between the two TCP endpoints.
    If either end does not support the more accurate feedback, they
    should both be able to fall back to classic ECN feedback.
    A more accurate ECN feedback extension should aim to traverse most
    middleboxes, including firewalls and Network Address Translators
    (NATs).  Further, a feedback mechanism should provide a method to
    fall back to classic ECN signalling if the new signal is
    suppressed by certain middleboxes.
    In order to avoid a fork in the TCP protocol specifications, if
    experiments with the new ECN feedback protocol are successful, the
    intention is to eventually update RFC 3168 for any TCP/ECN sender,
    not just for ConEx or DCTCP senders.  Then, future senders will be
    able to unilaterally deploy new behaviours that exploit the
    existence of more accurate ECN feedback in receivers (forward

Kuehlewind, et al. Informational [Page 10] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

    compatibility).  Conversely, even if another sender only needs one
    ECN feedback signal per RTT, it should be able to use more
    accurate ECN feedback and simply ignore the excess information.
 Furthermore, the receiver should not make assumptions about the
 mechanism that was used to set the markings nor about any
 interpretation or reaction to the congestion signal.  The receiver
 only needs to faithfully reflect congestion information back to the
 sender.

5. Design Approaches

 This section introduces some possible design approaches for TCP ECN
 feedback.  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
 provide accurate ECN feedback information as long as no ACK loss
 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
 schemes have different resilience characteristics depending on the
 number of bits used for the encoding.  While classic ECN provides
 reliable (but inaccurate) feedback of a maximum of one congestion
 signal per RTT, the proposed schemes do not implement an explicit
 acknowledgement mechanism for the feedback (as, e.g., the ECE/CWR
 exchange of [RFC3168]).

5.1. Redefinition of ECN/NS Header Bits

 Schemes in this category can additionally use the NS bit for
 capability negotiation during the TCP handshake exchange.  Thus a
 more accurate ECN could be negotiated without changing the classic
 ECN negotiation and thus being backwards compatible.
 Schemes in this category can simply redefine the ECN header flags,
 ECE and CWR, to encode the occurrence of a CE marking at the
 receiver.  This approach provides very limited resilience against
 loss of ACK, particularly pure ACKs (no payload and therefore
 delivered unreliably).

Kuehlewind, et al. Informational [Page 11] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

 A couple of schemes have been proposed so far:
 o  A naive 1-bit scheme that sends one ECE for each CE received could
    use CWR to increase robustness against ACK loss by introducing
    redundant information on the next ACK, but this is still
    vulnerable to ACK loss.
 o  The scheme defined for DCTCP [DCTCP], which toggles the ECE
    feedback on an immediate ACK whenever the CE marking changes, and
    otherwise feeds back delayed ACKs with the ECE value unchanged.
    Appendix A demonstrates that this scheme is 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,
 CWR, and NS, to represent a counter that signals the accumulated
 number of CE markings it has received.  Resilience against loss is
 better 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 performance.
 A number of coding schemes have been proposed so far in this
 category:
 o  A 3-bit counter scheme continuously feeds back the three least
    significant bits of a CE counter;
 o  A scheme that defines a standardized lookup table to map the eight
    codepoints onto either a CE counter or an ECT(1) counter.
 These proposed schemes provide accumulated information on CE marking
 feedback, similar to the number of acknowledged bytes in the TCP
 header.  Due to the limited number of bits, the ECN feedback
 information will wrap much more often than the acknowledgement field.
 Thus, feedback information could be lost due to a relatively small
 sequence of pure-ACK losses.  Resilience could be increased by
 introducing redundancy, e.g., send each counter increase two or more
 times.  Of course, any of these additional mechanisms will increase
 the complexity.  If the congestion rate is greater than the ACK rate
 (multiplied by the number of congestion marks that can be signaled
 per ACK), the congestion information cannot correctly be fed back.
 Covering the worst case (where every packet is CE marked) can
 potentially be realized by dynamically adapting the ACK rate and
 redundancy.  This again increases complexity and perhaps the
 signalling overhead as well.  Schemes that do not repurpose the ECN
 NS bit could still support the ECN Nonce.

Kuehlewind, et al. Informational [Page 12] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

5.2. Using Other Header Bits

 As seen in Figure 1, there are currently three unused flags in the
 TCP header.  The proposed 3-bit counter or codepoint schemes could be
 extended by one or more bits to add higher resilience against ACK
 loss.  The relative gain would be exponentially higher resilience
 against ACK loss, while the respective drawbacks would remain
 identical.
 Alternatively, a new method could standardize the use of the bits in
 the Urgent Pointer field (see [RFC6093]) to signal more bits of its
 congestion signal counter, but only whenever the Urgent Flag is not
 set.  As this is often the case, resilience could be increased
 without additional header overhead.
 Any proposal to use such bits would need to check the likelihood that
 some middleboxes might discard or 'normalize' the currently unused
 flag bits or a non-zero Urgent Pointer when the Urgent Flag is
 cleared.  If during experimentation certain bits have been proven to
 be usable, the assignment of any of these bits would then require an
 IETF standards action.

5.3. Using a TCP Option

 Alternatively, a new TCP option could be introduced, to help maintain
 the accuracy and integrity of ECN feedback between receiver and
 sender.  Such an option could provide higher resilience and even more
 information, e.g., as much as is provided by a proposal for SCTP that
 counts the number of CE marked packet [SCTP-ECN] since the last CWR
 was observed, or by ECN for RTP/UDP [RFC6679].  The latter explicitly
 provides the total number of packets during a connection where the IP
 ECN field is set to ECT(0), ECT(1), CE, or Not-ECT, as well as the
 number of lost packets.  However, deploying new TCP options has its
 own challenges.  Moreover, to actually achieve high resilience, this
 option would need to be carried by most or all ACKs as the receiver
 cannot know if and when ACKs may be dropped.  Thus, this approach
 would introduce considerable signalling overhead even though ECN
 feedback is not extremely critical information (in the worst case,
 loss will still be available to provide a strong congestion feedback
 signal).  Nevertheless, such a TCP option could be used in addition
 to a more accurate ECN feedback scheme in the TCP header or in
 addition to classic ECN, only when needed and when space is
 available.

Kuehlewind, et al. Informational [Page 13] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

6. Security Considerations

 ECN feedback information must only be used if the other information
 contained in a received TCP segment indicates that the congestion was
 genuinely part of the flow and not spoofed.  That is, the normal TCP
 acceptance techniques have to be used to verify that the segment is
 part of the flow before returning any contained ECN information, and,
 similarly, ECN feedback is only accepted on valid ACKs.
 Given ECN feedback is used as input for congestion control, the
 respective algorithm would not react appropriately if ECN feedback
 were lost and the resilience mechanism to recover it was inadequate.
 This resilience requirement is articulated in Section 4.  However, it
 should be noted that ECN feedback is not the last resort against
 congestion collapse, because if there is insufficient response to
 ECN, loss will ensue, and TCP will still react appropriately to loss.
 A receiver could suppress ECN feedback information leading to its
 connections consuming excess sender or network resources.  This
 problem is similar to that seen with the classic ECN feedback scheme
 and should be addressed by integrity checking as required in
 Section 4.

7. References

7.1. Normative References

 [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
            of Explicit Congestion Notification (ECN) to IP",
            RFC 3168, DOI 10.17487/RFC3168, September 2001,
            <http://www.rfc-editor.org/info/rfc3168>.
 [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
            Congestion Notification (ECN) Signaling with Nonces",
            RFC 3540, DOI 10.17487/RFC3540, June 2003,
            <http://www.rfc-editor.org/info/rfc3540>.

7.2. Informative References

 [DCTCP]    Bensley, S., Eggert, L., and D. Thaler, "Microsoft's
            Datacenter TCP (DCTCP): TCP Congestion Control for
            Datacenters", Work in Progress,
            draft-bensley-tcpm-dctcp-05, July 2015.
 [ECN-BENEFITS]
            Fairhurst, G. and M. Welzl, "The Benefits of using
            Explicit Congestion Notification (ECN)", Work in Progress
            draft-ietf-aqm-ecn-benefits-06, July 2015.

Kuehlewind, et al. Informational [Page 14] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

 [RFC896]   Nagle, J., "Congestion Control in IP/TCP Internetworks",
            RFC 896, DOI 10.17487/RFC0896, January 1984,
            <http://www.rfc-editor.org/info/rfc896>.
 [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
            Selective Acknowledgment Options", RFC 2018,
            DOI 10.17487/RFC2018, October 1996,
            <http://www.rfc-editor.org/info/rfc2018>.
 [RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
            Sooriyabandara, "TCP Performance Implications of Network
            Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
            December 2002, <http://www.rfc-editor.org/info/rfc3449>.
 [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
            Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
            <http://www.rfc-editor.org/info/rfc5681>.
 [RFC5690]  Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
            Acknowledgement Congestion Control to TCP", RFC 5690,
            DOI 10.17487/RFC5690, February 2010,
            <http://www.rfc-editor.org/info/rfc5690>.
 [RFC6093]  Gont, F. and A. Yourtchenko, "On the Implementation of the
            TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,
            January 2011, <http://www.rfc-editor.org/info/rfc6093>.
 [RFC6679]  Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
            and K. Carlberg, "Explicit Congestion Notification (ECN)
            for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
            2012, <http://www.rfc-editor.org/info/rfc6679>.
 [RFC6789]  Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed.,
            "Congestion Exposure (ConEx) Concepts and Use Cases",
            RFC 6789, DOI 10.17487/RFC6789, December 2012,
            <http://www.rfc-editor.org/info/rfc6789>.
 [SCTP-ECN] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream
            Control Transmission Protocol (SCTP)", Work in Progress,
            draft-stewart-tsvwg-sctpecn-05, January 2014.
 [TEST-RCV] Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
            Allow Senders to Identify Receiver Non-Compliance", Work
            in Progress, draft-moncaster-tcpm-rcv-cheat-03, July 2014.

Kuehlewind, et al. Informational [Page 15] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

Appendix A. Ambiguity of the More Accurate ECN Feedback in DCTCP

 As defined in [DCTCP], a DCTCP receiver feeds back ECE=0 on delayed
 ACKs as long as CE remains 0, and also immediately sends an ACK with
 ECE=0 when CE transitions to 1.  Similarly, it continually feeds back
 ECE=1 on delayed ACKs while CE remains 1 and immediately feeds back
 ECE=1 when CE transitions to 0.  A sender can unambiguously decode
 this scheme if there is never any ACK loss, and the sender assumes
 there will never be any ACK loss.
 The following two examples show that the feedback sequence becomes
 highly ambiguous to the sender if either of these conditions is
 broken.  Below, '0' represents ECE=0, '1' represents ECE=1, and '.'
 represents a gap of one segment between delayed ACKs.  Now imagine
 that the sender receives the following sequence of feedback on three
 pure ACKs:
    0.0.0
 When the receiver sent this sequence, it could have been any of the
 following four sequences:
 a.  0.0.0 (0 x CE)
 b.  010.0 (1 x CE)
 c.  0.010 (1 x CE)
 d.  01010 (2 x CE)
 where any of the 1s represent a possible pure ACK carrying ECE
 feedback that could have been lost.  If the sender guesses (a), it
 might be correct, or it might miss 1 or 2 congestion marks over 5
 packets.  Therefore, when confronted with this simple sequence (that
 is not contrived), a sender can guess that congestion might have been
 0%, 20%, or 40%, but it doesn't know which.
 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 between delayed ACKs, and it helps a lot if the
 distance is 1, i.e., no delayed ACKs.  However, even without delayed
 ACKs there will still be ambiguity whenever there are pure ACK
 losses.

Kuehlewind, et al. Informational [Page 16] RFC 7560 Requirements for More Accurate ECN Feedback August 2015

Acknowledgements

 Thanks to Gorry Fairhurst for his review and for ideas on CE-based
 integrity checking and to Mohammad Alizadeh for suggesting the need
 to avoid bias.
 Bob Briscoe was partly funded by the European Community under its
 Seventh Framework Programme through the Reducing Internet Transport
 Latency (RITE) project (ICT-317700) and through the Trilogy 2 project
 (ICT-317756).  The views expressed here are solely those of the
 authors, in the context of the mentioned funding projects.

Authors' Addresses

 Mirja Kuehlewind (editor)
 ETH Zurich
 Gloriastrasse 35
 Zurich  8092
 Switzerland
 Email: mirja.kuehlewind@tik.ee.ethz.ch
 Richard Scheffenegger
 NetApp, Inc.
 Am Euro Platz 2
 Vienna  1120
 Austria
 Phone: +43 1 3676811 3146
 Email: rs@netapp.com
 Bob Briscoe
 BT
 B54/77, Adastral Park
 Martlesham Heath
 Ipswich  IP5 3RE
 United Kingdom
 Phone: +44 1473 645196
 Email: ietf@bobbriscoe.net
 URI:   http://bobbriscoe.net/

Kuehlewind, et al. Informational [Page 17]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7560.txt · Last modified: 2015/08/27 02:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki