GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8087

Internet Engineering Task Force (IETF) G. Fairhurst Request for Comments: 8087 University of Aberdeen Category: Informational M. Welzl ISSN: 2070-1721 University of Oslo

                                                            March 2017
    The Benefits of Using Explicit Congestion Notification (ECN)

Abstract

 The goal of this document is to describe the potential benefits of
 applications using a transport that enables Explicit Congestion
 Notification (ECN).  The document outlines the principal gains in
 terms of increased throughput, reduced delay, and other benefits when
 ECN is used over a network path that includes equipment that supports
 Congestion Experienced (CE) marking.  It also discusses challenges
 for successful deployment of ECN.  It does not propose new algorithms
 to use ECN nor does it describe the details of implementation of ECN
 in endpoint devices (Internet hosts), routers, or other network
 devices.

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 7841.
 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/rfc8087.

Fairhurst & Welzl Informational [Page 1] RFC 8087 Benefits of ECN March 2017

Copyright Notice

 Copyright (c) 2017 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.  Benefit of Using ECN to Avoid Congestion Loss . . . . . . . .   5
   2.1.  Improved Throughput . . . . . . . . . . . . . . . . . . .   5
   2.2.  Reduced Head-of-Line Blocking . . . . . . . . . . . . . .   6
   2.3.  Reduced Probability of RTO Expiry . . . . . . . . . . . .   6
   2.4.  Applications That Do Not Retransmit Lost Packets  . . . .   7
   2.5.  Making Incipient Congestion Visible . . . . . . . . . . .   8
   2.6.  Opportunities for New Transport Mechanisms  . . . . . . .   8
 3.  Network Support for ECN . . . . . . . . . . . . . . . . . . .   9
   3.1.  The ECN Field . . . . . . . . . . . . . . . . . . . . . .  10
   3.2.  Forwarding ECN-Capable IP Packets . . . . . . . . . . . .  10
   3.3.  Enabling ECN in Network Devices . . . . . . . . . . . . .  11
   3.4.  Coexistence of ECN and Non-ECN Flows  . . . . . . . . . .  11
   3.5.  Bleaching and Middlebox Requirements to Deploy ECN  . . .  11
   3.6.  Tunneling ECN and the Use of ECN by Lower-Layer Networks   12
 4.  Using ECN across the Internet . . . . . . . . . . . . . . . .  12
   4.1.  Partial Deployment  . . . . . . . . . . . . . . . . . . .  13
   4.2.  Detecting Whether a Path Really Supports ECN  . . . . . .  13
   4.3.  Detecting ECN-Receiver Feedback Cheating  . . . . . . . .  14
 5.  Summary: Enabling ECN in Network Devices and Hosts  . . . . .  14
 6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
 7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   7.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
   7.2.  Informative References  . . . . . . . . . . . . . . . . .  16
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

Fairhurst & Welzl Informational [Page 2] RFC 8087 Benefits of ECN March 2017

1. Introduction

 Internet transports (such as TCP and Stream Control Transmission
 Protocol (SCTP)) are implemented in endpoints (Internet hosts) and
 are designed to detect and react to network congestion.  Congestion
 may be detected by loss of an IP packet or, if Explicit Congestion
 Notification (ECN) [RFC3168] is enabled, by the reception of a packet
 with a Congestion Experienced (CE) marking in the IP header.  Both of
 these are treated by transports as indications of congestion.  ECN
 may also be enabled by other transports: UDP applications that
 provide congestion control may enable ECN when they are able to
 correctly process the ECN signals [RFC8085] (e.g., ECN with RTP
 [RFC6679]).
 Active Queue Management (AQM) [RFC7567] is a class of techniques that
 can be used by network devices (a router, middlebox, or other device
 that forwards packets through the network) to manage the size of
 queues in network buffers.
 A network device that does not support AQM typically uses a drop-tail
 policy to drop excess IP packets when its queue becomes full.  The
 discard of packets is treated by transport protocols as a signal that
 indicates congestion on the end-to-end network path.  End-to-end
 transports, such as TCP, can cause a low level of loss while seeking
 to share capacity with other flows.  Although losses are not always
 due to congestion (loss may be due to link corruption, receiver
 overrun, etc.), endpoints have to conservatively presume that all
 loss is potentially due to congestion and reduce their rate.
 Observed loss therefore results in a congestion control reaction by
 the transport to reduce the maximum rate permitted by the sending
 endpoint.
 ECN makes it possible for the network to signal the presence of
 incipient congestion without incurring packet loss; it lets the
 network deliver some packets to an application that would otherwise
 have been dropped if the application or transport did not support
 ECN.  This packet-loss reduction is the most obvious benefit of ECN,
 but it is often relatively modest.  However, enabling ECN can also
 result in a number of beneficial side effects, some of which may be
 much more significant than the immediate packet-loss reduction from
 receiving a CE marking instead of dropping packets.  Several benefits
 reduce latency (e.g., reduced head-of-line blocking).
 The use of ECN is indicated in the ECN field [RFC3168], which is
 carried in the packet header of all IPv4 and IPv6 packets.  This
 field may be set to one of the four values shown in Figure 1.  The
 Not-ECT codepoint '00' indicates a packet that is not using ECN.  The
 ECT(0) codepoint '01' and the ECT(1) codepoint '10' both indicate

Fairhurst & Welzl Informational [Page 3] RFC 8087 Benefits of ECN March 2017

 that the transport protocol using the IP layer supports the use of
 ECN.  The CE codepoint '11' is set by an ECN-capable network device
 to indicate congestion to the transport endpoint.
 +-----+-----+---------+
 | ECN FIELD |  Name   |
 +-----+-----+---------+
 |  0  |  0  | Not-ECT |
 |  0  |  1  | ECT(1)  |
 |  1  |  0  | ECT(0)  |
 |  1  |  1  | CE      |
 +-----+-----+---------+
 Figure 1: The ECN Field in the IP Packet Header (based on [RFC3168])
 When an application uses a transport that enables use of ECN
 [RFC3168], the transport layer sets the ECT(0) or ECT(1) codepoint in
 the IP header of packets that it sends.  This indicates to network
 devices that they may mark, rather than drop, the ECN-capable IP
 packets.  An ECN-capable network device can then signal incipient
 congestion (network queuing) at a point before a transport
 experiences congestion loss or high queuing delay.  The marking is
 generally performed as the result of various AQM algorithms [RFC7567]
 where the exact combination of AQM/ECN algorithms does not need to be
 known by the transport endpoints.
 The focus of the document is on usage of ECN by transport- and
 application-layer flows, not its implementation in endpoint hosts,
 routers, and other network devices.

1.1. Terminology

 The following terms are used:
 AQM: Active Queue Management.
 CE: Congestion Experienced; a codepoint value '11' marked in the ECN
 field of the IP packet header.
 ECN-capable IP Packet: A packet where the ECN field is set to a non-
 zero ECN value (i.e., with ECT(0), ECT(1), or the CE codepoint).
 ECN-capable network device: An ECN-capable network device may
 forward, drop, or queue an ECN-capable packet and may choose to CE
 mark this packet when there is incipient congestion.

Fairhurst & Welzl Informational [Page 4] RFC 8087 Benefits of ECN March 2017

 ECN-capable transport/application: A transport that sends ECN-capable
 IP Packets, monitors reception of the ECN field, and generates
 appropriate feedback to control the rate of the sending endpoint to
 provide end-to-end congestion control.
 ECN field: A 2-bit field specified for use with explicit congestion
 signaling in the IPv4 and IPv6 packet headers.
 Endpoint: An Internet host that terminates a transport protocol
 connection across an Internet path.
 Incipient Congestion: The detection of congestion when it is
 starting, perhaps by a network device noting that the arrival rate
 exceeds the forwarding rate.
 Network device: A router, middlebox, or other device that forwards IP
 packets through the network.
 non-ECN-capable: A network device or endpoint that does not interpret
 the ECN field.  Such a device is not permitted to change the ECN
 codepoint.
 not-ECN-capable IP Packet: An IP packet with the ECN field set to a
 value of zero ('00').  A not-ECN-capable packet may be forwarded,
 dropped, or queued by a network device.

2. Benefit of Using ECN to Avoid Congestion Loss

 An ECN-capable network device is expected to CE mark an ECN-capable
 IP packet as a CE when an AQM method detects incipient congestion
 rather than drop the packet [RFC7567].  An application can benefit
 from this marking in several ways, which are detailed in the rest of
 this section.

2.1. Improved Throughput

 ECN seeks to avoid the inefficiency of dropping data that has already
 made it across at least part of the network path.
 ECN can improve the throughput of an application, although this
 increase in throughput is often not the most significant gain.  When
 an application uses a lightly to moderately loaded network path, the
 number of packets that are dropped due to congestion is small.  Using
 an example from Table 1 of [RFC3649], for a standard TCP sender with
 an RTT of 0.1 seconds, a packet size of 1500 bytes, and an average
 throughput of 1 Mbps, the average packet-drop ratio would be 0.02
 (i.e., 1 in 50 packets).  This translates into an approximate 2%

Fairhurst & Welzl Informational [Page 5] RFC 8087 Benefits of ECN March 2017

 throughput gain if ECN is enabled.  (Note that in heavy congestion,
 packet loss may be unavoidable with or without ECN.)

2.2. Reduced Head-of-Line Blocking

 Many Internet transports provide in-order delivery of received data
 segments to the applications they support.  For these applications,
 use of ECN can reduce the delay that can result when these
 applications experience packet loss.
 Packet loss may occur for various reasons.  One cause arises when an
 AQM scheme drops a packet as a signal of incipient congestion.
 Whatever the cause of loss, a missing packet needs to trigger a
 congestion control response.  A reliable transport also triggers
 retransmission to recover the lost data.  For a transport providing
 in-order delivery, this requires that the transport receiver stall
 (or wait) for all data that was sent ahead of a lost segment to be
 correctly received before it can forward any later data to the
 application.  A loss therefore creates a delay of at least one RTT
 after a loss event before data can be delivered to an application.
 We call this head-of-line blocking.  This is the usual requirement
 for TCP and SCTP.  Partially Reliable SCTP (PR-SCTP) [RFC3758], UDP
 [RFC768] [RFC8085], and the Datagram Congestion Control Protocol
 (DCCP) [RFC4340] provide a transport that does not provide
 reordering.
 By enabling ECN, a transport continues to receive in-order data when
 there is incipient congestion and can pass this data to the receiving
 application.  Use of ECN avoids the additional reordering delay in a
 reliable transport.  The sender still needs to make an appropriate
 congestion response to reduce the maximum transmission rate for
 future traffic, which usually will require a reduction in the sending
 rate [RFC8085].

2.3. Reduced Probability of RTO Expiry

 Some patterns of packet loss can result in a Retransmission Timeout
 (RTO), which causes a sudden and significant change in the allowed
 rate at which a transport/application can forward packets.  Because
 ECN provides an alternative to drop for network devices to signal
 incipient congestion, this can reduce the probability of loss and
 hence reduce the likelihood of RTO expiry.
 Internet transports/applications generally use an RTO timer as a last
 resort to detect and recover loss [RFC8085] [RFC5681].  Specifically,
 an RTO timer detects loss of a packet that is not followed by other
 packets, such as at the end of a burst of data segments or when an
 application becomes idle (either because the application has no

Fairhurst & Welzl Informational [Page 6] RFC 8087 Benefits of ECN March 2017

 further data to send or the network prevents sending further data,
 e.g., flow or congestion control at the transport layer).  This loss
 of the last segment (or last few segments) of a traffic burst is also
 known as a "tail loss".  Standard transport recovery methods, such as
 Fast Recovery [RFC5681], are often unable to recover from a tail
 loss.  This is because the endpoint receiver is unaware that the lost
 segments were actually sent and therefore generates no feedback
 [Fla13].  Retransmission of these segments relies on expiry of a
 transport retransmission timer.  This timer is also used to detect a
 lack of forwarding along a path.  Expiry of the RTO results in the
 consequent loss of state about the network path being used.  This
 typically includes resetting path estimates such as the RTT,
 reinitializing the congestion window, and possibly making updates to
 other transport state.  This can reduce the performance of the
 transport until it again adapts to the path.
 An ECN-capable network device cannot eliminate the possibility of
 tail loss because a drop may occur due to a traffic burst exceeding
 the instantaneous available capacity of a network buffer or as a
 result of the AQM algorithm (e.g., overload protection mechanisms
 [RFC7567]).  However, an ECN-capable network device that observes
 incipient congestion may be expected to buffer the IP packets of an
 ECN-capable flow and set a CE mark in one or more packet(s) rather
 than triggering packet drop.  Setting a CE mark signals incipient
 congestion without forcing the transport/application to enter
 retransmission timeout.  This reduces application-level latency and
 can improve the throughput for applications that send intermittent
 bursts of data.
 The benefit of avoiding retransmission loss is expected to be
 significant when ECN is used on TCP SYN/ACK packets [RFC5562] where
 the RTO interval may be large because TCP cannot base the timeout
 period on prior RTT measurements from the same connection.

2.4. Applications That Do Not Retransmit Lost Packets

 A transport that enables ECN can receive timely congestion signals
 without the need to retransmit packets each time it receives a
 congestion signal.
 Some latency-critical applications do not retransmit lost packets,
 yet they may be able to adjust their sending rate following detection
 of incipient congestion.  Examples of such applications include UDP-
 based services that carry Voice over IP (VoIP), interactive video, or
 real-time data.  The performance of many such applications degrades
 rapidly with increasing packet loss, and the transport/application
 may therefore employ mechanisms (e.g., packet forward error
 correction, data duplication, or media codec error concealment) to

Fairhurst & Welzl Informational [Page 7] RFC 8087 Benefits of ECN March 2017

 mitigate the immediate effect of congestion loss on the application.
 Some mechanisms consume additional network capacity, some require
 additional processing, and some contribute additional path latency
 when congestion is experienced.  By decoupling congestion control
 from loss, ECN can allow transports that support these applications
 to reduce their rate before the application experiences loss from
 congestion.  This can reduce the negative impact of triggering loss-
 hiding mechanisms with a direct positive impact on the quality
 experienced by the users of these applications.

2.5. Making Incipient Congestion Visible

 A characteristic of using ECN is that it exposes the presence of
 congestion on a network path to the transport and network layers,
 thus allowing information to be collected about the presence of
 incipient congestion.
 Recording the presence of CE-marked packets can provide information
 about the current congestion level experienced on a network path.  A
 network flow that only experiences CE marking and no loss implies
 that the sending endpoint is experiencing only congestion.  A network
 flow may also experience loss (e.g., due to queue overflow, AQM
 methods that protect other flows, link corruption, or loss in
 middleboxes).  When a mixture of CE marking and packet loss is
 experienced, transports and measurements need to assume there is
 congestion [RFC7567].  Therefore, an absence of CE marks does not
 indicate a path has not experienced congestion.
 The reception of CE-marked packets can be used to monitor the level
 of congestion by a transport/application or a network operator.  For
 example, ECN measurements are used by Congestion Exposure (ConEx)
 [RFC6789].  In contrast, metering packet loss is harder.

2.6. Opportunities for New Transport Mechanisms

 ECN can enable design and deployment of new algorithms in network
 devices and Internet transports.  Internet transports need to regard
 both loss and CE marking as an indication of congestion.  However,
 while the amount of feedback provided by drop ought naturally be
 minimized, this is not the case for ECN.  In contrast, an ECN-capable
 network device could provide richer (more frequent and fine-grained)
 indication of its congestion state to the transport.
 For any ECN-capable transport (ECT), the receiving endpoint needs to
 provide feedback to the transport sender to indicate that CE marks
 have been received.  [RFC3168] provides one method that signals once
 each round-trip time (RTT) that CE-marked packets have been received.

Fairhurst & Welzl Informational [Page 8] RFC 8087 Benefits of ECN March 2017

 A receiving endpoint may provide more detailed feedback to the
 congestion controller at the sender (e.g., describing the set of
 received ECN codepoints or indicating each received CE-marked
 packet).  Precise feedback about the number of CE marks encountered
 is supported by RTP when used over UDP [RFC6679] and has been
 proposed for SCTP [ST14] and TCP [ECN-FEEDBACK].
 More detailed feedback is expected to enable evolution of transport
 protocols allowing the congestion control mechanism to make a more
 appropriate decision on how to react to congestion.  Designers of
 transport protocols need to consider not only how network devices
 CE-mark packets but also how the control loop in the application/
 transport reacts to reception of these CE-marked packets.
 Benefit has been noted when packets are CE marked early using an
 instantaneous queue, and if the receiving endpoint provides feedback
 about the number of packet marks encountered, an improved sender
 behavior has been shown to be possible, e.g, Data Center TCP (DCTCP)
 [AL10].  DCTCP is targeted at controlled environments such as a data
 center.  This is a work in progress, and it is currently unknown
 whether or how such behavior could be safely introduced into the
 Internet.  Any update to an Internet transport protocol requires
 careful consideration of the robustness of the behavior when working
 with endpoints or network devices that were not designed for the new
 congestion reaction.

3. Network Support for ECN

 For an application to use ECN requires that the endpoints enable ECN
 within the transport being used.  It also requires that all network
 devices along the path at least forward IP packets that set a
 non-zero ECN codepoint.
 ECN can be deployed both in the general Internet and in controlled
 environments:
 o  ECN can be incrementally deployed in the general Internet.  The
    IETF has provided guidance on configuration and usage in
    [RFC7567].
 o  ECN may be deployed within a controlled environment, for example,
    within a data center or within a well-managed private network.
    This use of ECN may be tuned to the specific use case.  An example
    is DCTCP [AL10] [DCTCP].

Fairhurst & Welzl Informational [Page 9] RFC 8087 Benefits of ECN March 2017

 Early experience of using ECN across the general Internet encountered
 a number of operational difficulties when the network path either
 failed to transfer ECN-capable packets or inappropriately changed the
 ECN codepoints [BA11].  A recent survey reported a growing support
 for network paths to pass ECN codepoints [TR15].
 The remainder of this section identifies what is needed for network
 devices to effectively support ECN.

3.1. The ECN Field

 The current IPv4 and IPv6 specifications assign usage of 2 bits in
 the IP header to carry the ECN codepoint.  This 2-bit field was
 reserved in [RFC2474] and assigned in [RFC3168].
 [RFC4774] discusses some of the issues in defining alternate
 semantics for the ECN field and specifies requirements for a safe
 coexistence in an Internet that could include routers that do not
 understand the defined alternate semantics.
 Some network devices were configured to use a routing hash that
 included the set of 8 bits forming the now deprecated Type of Service
 (TOS) field [RFC1349].  The present use of this field assigns 2 of
 these bits to carry the ECN field.  This is incompatible with use in
 a routing hash because it could lead to IP packets that carry a CE
 mark being routed over a different path to those packets that carried
 an ECT mark.  The resultant reordering would impact the performance
 of transport protocols (such as TCP or SCTP) and UDP-based
 applications that are sensitive to reordering.  A network device that
 conforms to this older specification needs to be updated to the
 current specifications [RFC2474] to support ECN.  Configuration of
 network devices must note that the ECN field may be updated by any
 ECN-capable network device along a path.

3.2. Forwarding ECN-Capable IP Packets

 Not all network devices along a path need to be ECN-capable (i.e.,
 perform CE marking).  However, all network devices need to be
 configured not to drop packets solely because the ECT(0) or ECT(1)
 codepoints are used.
 Any network device that does not perform CE marking of an ECN-capable
 packet can be expected to drop these packets under congestion.
 Applications that experience congestion at these network devices do
 not see any benefit from enabling ECN.  However, they may see benefit
 if the congestion were to occur within a network device that did
 support ECN.

Fairhurst & Welzl Informational [Page 10] RFC 8087 Benefits of ECN March 2017

3.3. Enabling ECN in Network Devices

 Network devices should use an AQM algorithm that CE-marks ECN-capable
 traffic when making decisions about the response to congestion
 [RFC7567].  An ECN method should set a CE mark on ECN-capable packets
 in the presence of incipient congestion.  A CE-marked packet will be
 interpreted as an indication of incipient congestion by the transport
 endpoints.
 There is an opportunity to design an AQM method for an ECN-capable
 network device that differs from an AQM method designed to drop
 packets.  [RFC7567] states that the network device should allow this
 behavior to be configurable.
 [RFC3168] describes a method in which a network device sets the CE
 mark at the time that the network device would otherwise have dropped
 the packet.  While it has often been assumed that network devices
 should CE-mark packets at the same level of congestion at which they
 would otherwise have dropped them, [RFC7567] recommends that network
 devices allow independent configuration of the settings for AQM
 dropping and ECN marking.  Such separate configuration of the drop
 and mark policies is supported in some network devices.

3.4. Coexistence of ECN and Non-ECN Flows

 Network devices need to be able to forward all IP flows and provide
 appropriate treatment for both ECN and non-ECN traffic.
 The design considerations for an AQM scheme supporting ECN needs to
 consider the impact of queueing during incipient congestion.  For
 example, a simple AQM scheme could choose to queue ECN-capable and
 non-ECN-capable flows in the same queue with an ECN scheme that
 CE-marks packets during incipient congestion.  The CE-marked packets
 that remain in the queue during congestion can continue to contribute
 to queueing delay.  In contrast, non-ECN-capable packets would
 normally be dropped by an AQM scheme under incipient congestion.
 This difference in queueing is one motivation for consideration of
 more advanced AQM schemes and may provide an incentive for enabling
 flow isolation using scheduling [RFC7567].  The IETF is defining
 methods to evaluate the suitability of AQM schemes for deployment in
 the general Internet [RFC7928].

3.5. Bleaching and Middlebox Requirements to Deploy ECN

 Network devices should not be configured to change the ECN codepoint
 in the packets that they forward, except to set the CE codepoint to
 signal incipient congestion.

Fairhurst & Welzl Informational [Page 11] RFC 8087 Benefits of ECN March 2017

 Cases have been noted where an endpoint sends a packet with a
 non-zero ECN mark, but the packet is received by the remote endpoint
 with a zero ECN codepoint [TR15].  This could be a result of a policy
 that erases or "bleaches" the ECN codepoint values at a network edge
 (resetting the codepoint to zero).  Bleaching may occur for various
 reasons (including normalizing packets to hide which equipment
 supports ECN).  This policy prevents use of ECN by applications.
 When ECN-capable IP packets, marked as ECT(0) or ECT(1), are
 re-marked to non-ECN-capable (i.e., the ECN field is set to the zero
 codepoint), this could result in the packets being dropped by
 ECN-capable network devices further along the path.  This eliminates
 the advantage of using of ECN.
 A network device must not change a packet with a CE mark to a zero
 codepoint; if the network device decides not to forward the packet
 with the CE mark, it has to instead drop the packet and not bleach
 the marking.  This is because a CE-marked packet has already received
 ECN treatment in the network, and re-marking it would then hide the
 congestion signal from the receiving endpoint.  This eliminates the
 benefits of ECN.  It can also slow down the response to congestion
 compared to using AQM because the transport will only react if it
 later discovers congestion by some other mechanism.
 Prior to [RFC2474], a previous usage assigned the bits now forming
 the ECN field as a part of the now deprecated TOS field [RFC1349].  A
 network device that conforms to this older specification was allowed
 to re-mark or erase the ECN codepoints, and such equipment needs to
 be updated to the current specifications in order to support ECN.

3.6. Tunneling ECN and the Use of ECN by Lower-Layer Networks

 Some networks may use ECN internally or tunnel ECN (e.g., for traffic
 engineering or security).  These methods need to ensure that the ECN
 field of the tunnel packets is handled correctly at the ingress and
 egress of the tunnel.  Guidance on the correct use of ECN is provided
 in [RFC6040].
 Further guidance on the encapsulation and use of ECN by non-IP
 network devices is provided in [ECN-ENCAP].

4. Using ECN across the Internet

 A receiving endpoint needs to report the loss it experiences when it
 uses loss-based congestion control.  So also, when ECN is enabled, a
 receiving endpoint must correctly report the presence of CE marks by
 providing a mechanism to feed this congestion information back to the
 sending endpoint [RFC3168] [RFC8085], thus enabling the sender to

Fairhurst & Welzl Informational [Page 12] RFC 8087 Benefits of ECN March 2017

 react to experienced congestion.  This mechanism needs to be designed
 to operate robustly across a wide range of Internet path
 characteristics.  This section describes partial deployment, that is,
 how ECN-enabled endpoints can continue to work effectively over a
 path that experiences misbehaving network devices or when an endpoint
 does not correctly provide feedback of ECN information.

4.1. Partial Deployment

 Use of ECN is negotiated between the endpoints prior to using the
 mechanism.
 ECN has been designed to allow incremental partial deployment
 [RFC3168].  Any network device can choose to use either ECN or some
 other loss-based policy to manage its traffic.  Similarly, transport/
 application negotiation allows sending and receiving endpoints to
 choose whether ECN will be used to manage congestion for a particular
 network flow.

4.2. Detecting Whether a Path Really Supports ECN

 Internet transports and applications need to be robust to the variety
 and sometimes varying path characteristics that are encountered in
 the general Internet.  They need to monitor correct forwarding of ECN
 over the entire path and duration of a session.
 To be robust, applications and transports need to be designed with
 the expectation of heterogeneous forwarding (e.g., where some IP
 packets are CE marked by one network device and some by another,
 possibly using a different AQM algorithm, or when a combination of CE
 marking and loss-based congestion indications are used).  Note that
 [RFC7928] describes methodologies for evaluating AQM schemes.
 A transport/application also needs to be robust to path changes.  A
 change in the set of network devices along a path could impact the
 ability to effectively signal or use ECN across the path, e.g., when
 a path changes to use a middlebox that bleaches ECN codepoints (see
 Section 3.5).
 A sending endpoint can check that any CE marks applied to packets
 received over the path are indeed delivered to the remote receiving
 endpoint and that appropriate feedback is provided.  (This could be
 done by a sender setting a known CE codepoint for specific packets in
 a network flow and then checking whether the remote endpoint
 correctly reports these marks [ECN-FALLBACK] [TR15].)  If a sender
 detects persistent misuse of ECN, it needs to fall back to using
 loss-based recovery and congestion control.  Guidance on a suitable
 transport reaction is provided in [ECN-FALLBACK].

Fairhurst & Welzl Informational [Page 13] RFC 8087 Benefits of ECN March 2017

4.3. Detecting ECN-Receiver Feedback Cheating

 Appropriate feedback requires that the endpoint receiver not try to
 conceal reception of CE-marked packets in the ECN feedback
 information provided to the sending endpoint [RFC7567].  Designers of
 applications/transports are therefore encouraged to include
 mechanisms that can detect this misbehavior.  If a sending endpoint
 detects that a receiver is not correctly providing this feedback, it
 needs to fall back to using loss-based recovery instead of ECN.

5. Summary: Enabling ECN in Network Devices and Hosts

 This section summarizes the benefits of deploying and using ECN
 within the Internet.  It also provides a list of prerequisites to
 achieve ECN deployment.
 Application developers should, where possible, use transports that
 enable ECN.  Applications that directly use UDP need to provide
 support to implement the functions required for ECN [RFC8085].  Once
 enabled, an application that uses a transport that supports ECN will
 experience the benefits of ECN as network deployment starts to enable
 ECN.  The application does not need to be rewritten to gain these
 benefits.  Figure 2 summarizes the key benefits.
 +---------+-----------------------------------------------------+
 | Section | Benefit                                             |
 +---------+-----------------------------------------------------+
 |   2.1   | Improved Throughput                                 |
 |   2.2   | Reduced Head-of-Line Blocking                       |
 |   2.3   | Reduced Probability of RTO Expiry                   |
 |   2.4   | Applications that do not Retransmit Lost Packets    |
 |   2.5   | Making Incipient Congestion Visible                 |
 |   2.6   | Opportunities for New Transport Mechanisms          |
 +---------+-----------------------------------------------------+
                   Figure 2: Summary of Key Benefits
 Network operators and people configuring network devices should
 enable ECN [RFC7567].
 Prerequisites for network devices (including IP routers) to enable
 use of ECN include:
 o  A network device that updates the ECN field in IP packets must use
    IETF-specified methods (see Section 3.1).
 o  A network device may support alternate ECN semantics (see
    Section 3.1).

Fairhurst & Welzl Informational [Page 14] RFC 8087 Benefits of ECN March 2017

 o  A network device must not choose a different network path solely
    because a packet carries a CE-codepoint set in the ECN Field;
    CE-marked packets need to follow the same path as packets with an
    ECT(0) or ECT(1) codepoint (see Section 3.1).  Network devices
    need to be configured not to drop packets solely because the
    ECT(0) or ECT(1) codepoints are used (see Section 3.2).
 o  An ECN-capable network device should correctly update the ECN
    codepoint of ECN-capable packets in the presence of incipient
    congestion (see Section 3.3).
 o  Network devices need to be able to forward both ECN-capable and
    not-ECN-capable flows (see Section 3.4).
 o  A network device must not change a packet with a CE mark to a not-
    ECN-capable codepoint ('00'); if the network device decides not to
    forward the packet with the CE mark, it has to instead drop the
    packet and not bleach the marking (see Section 3.5).
 Prerequisites for network endpoints to enable use of ECN include the
 following:
 o  An application should use an Internet transport that can set and
    receive ECN marks (see Section 4).
 o  An ECN-capable transport/application must return feedback
    indicating congestion to the sending endpoint and perform an
    appropriate congestion response (see Section 4).
 o  An ECN-capable transport/application should detect paths where
    there is persistent misuse of ECN and fall back to not sending
    ECT(0) or ECT(1) (see Section 4.2).
 o  Designers of applications/transports are encouraged to include
    mechanisms that can detect and react appropriately to misbehaving
    receivers that fail to report CE-marked packets (see Section 4.3).

6. Security Considerations

 This document introduces no new security considerations.  Each RFC
 listed in this document discusses the security considerations of the
 specification it contains.

Fairhurst & Welzl Informational [Page 15] RFC 8087 Benefits of ECN March 2017

7. References

7.1. Normative References

 [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
            "Definition of the Differentiated Services Field (DS
            Field) in the IPv4 and IPv6 Headers", RFC 2474,
            DOI 10.17487/RFC2474, December 1998,
            <http://www.rfc-editor.org/info/rfc2474>.
 [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>.
 [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
            Notification", RFC 6040, DOI 10.17487/RFC6040, November
            2010, <http://www.rfc-editor.org/info/rfc6040>.
 [RFC7567]  Baker, F., Ed. and G. Fairhurst, Ed., "IETF
            Recommendations Regarding Active Queue Management",
            BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
            <http://www.rfc-editor.org/info/rfc7567>.
 [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
            Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
            March 2017, <http://www.rfc-editor.org/info/rfc8085>.

7.2. Informative References

 [AL10]     Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel,
            P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data
            Center TCP (DCTCP)", ACM SIGCOMM Computer Communication
            Review, Volume 40, Issue 4, pages 63-74,
            DOI 10.1145/1851182.1851192, October 2010.
 [BA11]     Bauer, Steven., Beverly, Robert., and Arthur. Berger,
            "Measuring the State of ECN Readiness in Servers, Clients,
            and Routers", Proceedings of the 2011 ACM SIGCOMM
            Conference on ICM, pages 171-180,
            DOI 10.1145/2068816.2068833, November 2011.
 [DCTCP]    Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P.,
            and G. Judd, "Microsoft's Datacenter TCP (DCTCP): TCP
            Congestion Control for Datacenters", Work in Progress,
            draft-bensley-tcpm-dctcp-05, July 2015.

Fairhurst & Welzl Informational [Page 16] RFC 8087 Benefits of ECN March 2017

 [ECN-ENCAP]
            Briscoe, B., Kaippallimalil, J., and P. Thaler,
            "Guidelines for Adding Congestion Notification to
            Protocols that Encapsulate IP", Work in Progress,
            draft-ietf-tsvwg-ecn-encap-guidelines-07, July 2016.
 [ECN-FALLBACK]
            Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path
            Probing and Fallback", Work in Progress,
            draft-kuehlewind-tcpm-ecn-fallback-01, September 2013.
 [ECN-FEEDBACK]
            Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
            Accurate ECN Feedback in TCP", Work in Progress,
            draft-ietf-tcpm-accurate-ecn-02, October 2016.
 [Fla13]    Flach, Tobias., Dukkipati, Nandita., Terzis, Andreas.,
            Raghavan, Barath., Cardwell, Neal., Cheng, Yuchung., Jain,
            Ankur., Hao, Shuai., Katz-Bassett, Ethan., and Ramesh.
            Govindan, "Reducing web latency: the virtue of gentle
            aggression", ACM SIGCOMM Computer Communication
            Review, Volume 43, Issue 4, pages 159-170,
            DOI 10.1145/2534169.2486014, October 2013.
 [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
            DOI 10.17487/RFC0768, August 1980,
            <http://www.rfc-editor.org/info/rfc768>.
 [RFC1349]  Almquist, P., "Type of Service in the Internet Protocol
            Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992,
            <http://www.rfc-editor.org/info/rfc1349>.
 [RFC3649]  Floyd, S., "HighSpeed TCP for Large Congestion Windows",
            RFC 3649, DOI 10.17487/RFC3649, December 2003,
            <http://www.rfc-editor.org/info/rfc3649>.
 [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
            Conrad, "Stream Control Transmission Protocol (SCTP)
            Partial Reliability Extension", RFC 3758,
            DOI 10.17487/RFC3758, May 2004,
            <http://www.rfc-editor.org/info/rfc3758>.
 [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
            Congestion Control Protocol (DCCP)", RFC 4340,
            DOI 10.17487/RFC4340, March 2006,
            <http://www.rfc-editor.org/info/rfc4340>.

Fairhurst & Welzl Informational [Page 17] RFC 8087 Benefits of ECN March 2017

 [RFC4774]  Floyd, S., "Specifying Alternate Semantics for the
            Explicit Congestion Notification (ECN) Field", BCP 124,
            RFC 4774, DOI 10.17487/RFC4774, November 2006,
            <http://www.rfc-editor.org/info/rfc4774>.
 [RFC5562]  Kuzmanovic, A., Mondal, A., Floyd, S., and K.
            Ramakrishnan, "Adding Explicit Congestion Notification
            (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562,
            DOI 10.17487/RFC5562, June 2009,
            <http://www.rfc-editor.org/info/rfc5562>.
 [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>.
 [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>.
 [RFC7928]  Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and
            D. Ros, "Characterization Guidelines for Active Queue
            Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July
            2016, <http://www.rfc-editor.org/info/rfc7928>.
 [ST14]     Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream
            Control Transmission Protocol (SCTP)", Work in Progress,
            draft-stewart-tsvwg-sctpecn-05, January 2014.
 [TR15]     Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano,
            Learmonth, Iain., and Gorry.  Fairhurst, "Enabling
            Internet-Wide Deployment of Explicit Congestion
            Notification", Lecture Notes in Computer Science, Volume
            8995, pp 193-205, DOI 10.1007/978-3-319-15509-8_15, March
            2015.

Fairhurst & Welzl Informational [Page 18] RFC 8087 Benefits of ECN March 2017

Acknowledgements

 The authors were partly funded by the European Community under its
 Seventh Framework Programme through the Reducing Internet Transport
 Latency (RITE) project (ICT-317700).  The views expressed are solely
 those of the authors.
 The authors would like to thank the following people for their
 comments on prior draft versions of this document: Bob Briscoe, David
 Collier-Brown, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes
 Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie,
 and other members of the TSVWG and AQM working groups.

Authors' Addresses

 Godred Fairhurst
 University of Aberdeen
 School of Engineering, Fraser Noble Building
 Aberdeen  AB24 3UE
 United Kingdom
 Email: gorry@erg.abdn.ac.uk
 Michael Welzl
 University of Oslo
 PO Box 1080 Blindern
 Oslo  N-0316
 Norway
 Phone: +47 22 85 24 20
 Email: michawe@ifi.uio.no

Fairhurst & Welzl Informational [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8087.txt · Last modified: 2017/03/07 22:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki