[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                         N. Khademi
Internet-Draft                                                  M. Welzl
Updates: 3168,4774 (if approved)                      University of Oslo
Intended status: Standards Track                             G. Armitage
Expires: December 2, 2016                        Swinburne University of
                                                              Technology
                                                            G. Fairhurst
                                                  University of Aberdeen
                                                            May 31, 2016


 Updating the Explicit Congestion Notification (ECN) Congestion Control
                                Response
                  draft-khademi-tsvwg-ecn-response-00

Abstract

   RFC3168 and RFC4774 state that, upon the receipt by an ECN-Capable
   transport of a single CE packet, the congestion control algorithms
   followed at the end-systems MUST be essentially the same as the
   congestion control response to a single dropped packet.  This
   document relaxes this rule in order to encourage experimentation with
   different backoff strategies.  This sender-side update makes it
   possible to achieve greater benefits with ECN, encouraging wider ECN
   deployment.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 2, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Khademi, et al.         Expires December 2, 2016                [Page 1]


Internet-Draft                ECN-response                      May 2016


   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
   2.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Why Use ECN to Vary the Degree of Backoff? . . . . . . . .  4
     2.2.  Focus on ECN as Defined in RFC3168 . . . . . . . . . . . .  5
   3.  Updating the Sender-side ECN Reaction  . . . . . . . . . . . .  5
     3.1.  RFC 2119 . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Update to RFCs 3168 and 4774 . . . . . . . . . . . . . . .  5
     3.3.  ABE: An Experiment That Follows the New Rule . . . . . . .  6
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  Revision Information . . . . . . . . . . . . . . . . . . . . .  7
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






















Khademi, et al.         Expires December 2, 2016                [Page 2]


Internet-Draft                ECN-response                      May 2016


1.  Introduction

   Explicit Congestion Notification (ECN) is specified in [RFC3168].  It
   allows a network device that uses Active Queue Management (AQM) to
   set the Congestion Experienced (CE) codepoint in the ECN field of the
   IP packet header, rather than to drop ECN-capable packets when
   incipient congestion is detected.  When an ECN-capable transport is
   used over a path that supports ECN, this provides the opportunity for
   flows to improve their performance in the presence of incipient
   congestion [I-D.AQM-ECN-benefits].

   [RFC3168] not only specifies the router use of the ECN field, it also
   specifies a TCP procedure for using ECN.  This states that a TCP
   sender should treat the ECN indication of congestion in the same way
   as that of a non-ECN-Capable TCP flow experiencing loss, by halving
   the congestion window "cwnd" and by reducing the slow start threshold
   "ssthresh".  [RFC5681] stipulates that TCP congestion control sets
   "ssthresh" to max(FlightSize / 2, 2*SMSS) in response to packet loss.
   This corresponds to a backoff multiplier of 0.5 (halving cwnd and
   sshthresh after packet loss).  Consequently, a standard TCP flow
   using this reaction needs significant network queue space: it can
   only fully utilise a bottleneck when the length of the link queue (or
   the AQM dropping threshold) is at least the bandwidth-delay product
   (BDP) of the flow.

   A backoff multiplier of 0.5 is not the only available strategy.  As
   defined in [I-D.CUBIC], CUBIC multiplies the current cwnd by 0.7 in
   response to loss ( the Linux implementation of CUBIC has used a
   multiplier of 0.7 since kernel version 2.6.25 released in 2008).
   Consequently, CUBIC utilises paths well even when the bottleneck
   queue is shorter than the bandwidth-delay product of the flow.
   However, in the case of a DropTail (FIFO) queue without AQM, such
   less-aggressive backoff increases the risk of creating a standing
   queue [CODEL2012].

   Devices implementing AQM are likely to be the dominant (and possibly
   only) source of ECN CE-marking for packets from ECN-capable senders.
   AQM mechanisms typically strive to maintain a small average queue
   length, regardless of the bandwidth-delay product of flows passing
   through them.  Receipt of an ECN CE-mark might therefore reasonably
   be taken to indicate that a small bottleneck queue exists in the
   path, and hence the TCP flow would benefit from using a less
   aggressive backoff multiplier.  Such behavior is however prohibited
   by the rules in [RFC3168].

   ECN has seen little deployment so far.  Apple recently announced
   their intention to enable ECN in iOS 9 and OS X 10.11 devices
   [WWDC2015].  By 2014, server-side ECN negotiation was observed to be



Khademi, et al.         Expires December 2, 2016                [Page 3]


Internet-Draft                ECN-response                      May 2016


   provided by the majority of the top million web servers [PAM2015],
   and only 0.5% of websites incurred additional connection setup
   latency using RFC3168-compliant ECN-fallback mechanisms.  [RFC7567]
   states that "deployed AQM algorithms SHOULD support Explicit
   Congestion Notification (ECN) as well as loss to signal congestion to
   endpoints" and [I-D.AQM-ECN-benefits] encourages this deployment.
   However, the limitation of [RFC3168] restricts a sender to react to
   notification of a CE-mark in the same way as if a packet was lost.
   This prohibits experimentation with ECN mechanisms that could yield
   greater benefits.  This specification therefore relaxes this
   constraint.


2.  Discussion

2.1.  Why Use ECN to Vary the Degree of Backoff?

   The classic rule-of-thumb dictates that a transport provides a BDP of
   bottleneck buffering if a TCP connection wishes to optimise path
   utilisation.  A single TCP connection running through such a
   bottleneck will have opened cwnd up to 2*BDP by the time packet loss
   occurs.  [RFC5681]'s halving of cwnd and ssthresh pushes the TCP
   connection back to allowing only a BDP of packets in flight -- just
   sufficient to maintain 100% utilisation of the network path.

   AQM schemes like CoDel [I-D.CoDel] and PIE [I-D.PIE] use congestion
   notifications to constrain the queuing delays experienced by packets,
   rather than in response to impending or actual bottleneck buffer
   exhaustion.  With current default delay targets, CoDel and PIE both
   effectively emulate a shallow buffered bottleneck (section II,
   [ABE2015]) while allowing short traffic bursts into the queue.  This
   interacts acceptably for TCP connections over low BDP paths, or
   highly multiplexed scenarios (many concurrent TCP connections).
   However, it interacts badly with lightly-multiplexed cases (few
   concurrent connections) over a high BDP path.  Conventional TCP
   backoff in such cases leads to gaps in packet transmission and under-
   utilisation of the path.

   The idea to react differently to loss upon detecting an ECN CE-mark
   pre-dates [ABE2015].  [ICC2002] also proposed using ECN CE-marks to
   modify TCP congestion control behaviour, using a larger
   multiplicative decrease factor in conjunction with a smaller additive
   increase factor to work with RED-based bottlenecks that were not
   necessarily configured to emulate a shallow queue.







Khademi, et al.         Expires December 2, 2016                [Page 4]


Internet-Draft                ECN-response                      May 2016


2.2.  Focus on ECN as Defined in RFC3168

   Some mechanisms rely on ECN semantics that differ from the
   definitions in [RFC3168] -- for example, Congestion Exposure (ConEx)
   [RFC7713] and DCTCP [I-D.ietf-tcpm-dctcp] need more accurate ECN
   information than the feedback mechanism in [RFC3168] offers (defined
   in [I-D.ietf-tcpm-accurate-ecn]).  Such mechanisms allow a sending
   rate adjustment more frequent than each RTT.  These mechanisms are
   out of the scope of the current document.


3.  Updating the Sender-side ECN Reaction

   This section specifies an update to [RFC3168] (and corresponding text
   in [RFC4774]) and refers to an experiment that is possible within the
   framework provided by the update.

3.1.  RFC 2119

   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 [RFC2119].

3.2.  Update to RFCs 3168 and 4774

   This document specifies an update to the TCP sender reaction that
   follows when the TCP receiver signals that ECN CE-marked packets have
   been received.

   [RFC3168] and [RFC4774] contain the following text:

   "Upon the receipt by an ECN-Capable transport of a single CE packet,
   the congestion control algorithms followed at the end-systems MUST be
   essentially the same as the congestion control response to a *single*
   dropped packet.  For example, for ECN-Capable TCP the source TCP is
   required to halve its congestion window for any window of data
   containing either a packet drop or an ECN indication."

   This memo updates the preceding text by replacing it with the
   following text:

   "Upon the receipt by an ECN-Capable transport of a single CE packet,
   the congestion control algorithms followed at the end-systems MUST
   make a congestion control response as specified in [RFC3168] or its
   updates.  For example, for ECN-Capable TCP the source TCP could halve
   its congestion window for any window of data containing either a
   packet drop or an ECN indication."




Khademi, et al.         Expires December 2, 2016                [Page 5]


Internet-Draft                ECN-response                      May 2016


   The first paragraph of Section 6.1.2, "The TCP Sender", in [RFC3168]
   contains the following text:

   "If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK
   packet with the ECN-Echo flag set in the TCP header), then the sender
   knows that congestion was encountered in the network on the path from
   the sender to the receiver.  The indication of congestion should be
   treated just as a congestion loss in non-ECN-Capable TCP.  That is,
   the TCP source halves the congestion window "cwnd" and reduces the
   slow start threshold "ssthresh"."

   This memo updates the preceding text by replacing it with the
   following text:

   "If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK
   packet with the ECN-Echo flag set in the TCP header), then the sender
   knows that congestion was encountered in the network on the path from
   the sender to the receiver.  An indication of congestion, signalled
   by reception of the ECN-Echo flag (with the semantics defined in
   [RFC3168]) MUST produce a rate reduction of at least 15%, so that
   flows sharing the same bottleneck can increase their share of the
   capacity.  The indication of congestion could be treated in the same
   way as if the flow had experienced loss, but future congestion
   control methods are allowed to specify a reduction that is less than
   the reduction for congestion loss.

   An ECN-capable network device cannot eliminate the possibility of
   packet loss.  A drop may still occur due to a traffic burst exceeding
   the instantaneous available capacity of a network buffer or as a
   result of the AQM algorithm (overload protection mechanisms, etc
   [RFC7567]).  Whatever the cause of loss, detection of a missing
   packet needs to trigger the standard loss-based congestion control
   response".  This update explicitly does not change the use of
   standard TCP mechanisms following loss, as required in [RFC3168].

3.3.  ABE: An Experiment That Follows the New Rule

   This update to [RFC3168] enables experimentation with a different
   backoff behavior in response to a CE-mark than in response to packet
   loss.  One experiment, called "Alternative Backoff with ECN" (ABE),
   is based upon [ABE2015] and defined in [I-D.ABE].


4.  Acknowledgements

   The authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by
   the European Community under its Seventh Framework Programme through
   the Reducing Internet Transport Latency (RITE) project (ICT-317700).



Khademi, et al.         Expires December 2, 2016                [Page 6]


Internet-Draft                ECN-response                      May 2016


   The views expressed are solely those of the authors.


5.  IANA Considerations

   XX RFC ED - PLEASE REMOVE THIS SECTION XXX

   This memo includes no request to IANA.


6.  Security Considerations

   The described method is a sender-side only transport change, and does
   not change the protocol messages exchanged.  The security
   considerations of [RFC3168] therefore still apply.

   A congestion control backoff that is less in response to ECN than the
   response to a packet loss can lead to a change in the capacity
   achieved when flows share a network bottleneck.  This can result in
   redistribution of capacity between sharing flows, potentially
   resulting in unfairness in the way that capacity is shared.  This
   potential gain applies only to ECN-marked packets using the updated
   method (and not to detected packet loss).  Similar unfairness can be
   exhibited by congestion control mechanisms that have been used in the
   Internet for many years (e.g., CUBIC [I-D.CUBIC]).  Unfairness may
   also be a result of other factors, including the round trip time
   experienced by a flow.

   Packet loss can be expected from an AQM algorithm experiencing
   persistent queuing, but could also imply the presence of faulty
   equipment or media in a path, or it may imply the presence of
   congestion [RFC7567].  The update does not change the congestion
   control response to packet loss, and will therefore not lead to
   congestion collapse.


7.  Revision Information

   XX RFC ED - PLEASE REMOVE THIS SECTION XXX

   -00. draft-khademi-tsvwg-ecn-response-00 and
   draft-khademi-tcpm-alternativebackoff-ecn-00 replace
   draft-khademi-alternativebackoff-ecn-03, following discussion in the
   TSVWG and TCPM working groups.


8.  References




Khademi, et al.         Expires December 2, 2016                [Page 7]


Internet-Draft                ECN-response                      May 2016


8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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>.

   [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>.

   [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>.

   [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>.

8.2.  Informative References

   [ABE2015]  Khademi, N., Welzl, M., Armitage, G., Kulatunga, C., Ros,
              D., Fairhurst, G., Gjessing, S., and S. Zander,
              "Alternative Backoff: Achieving Low Latency and High
              Throughput with ECN and AQM", CAIA Technical Report CAIA-
              TR-150710A, Swinburne University of Technology, July 2015,
              <http://caia.swin.edu.au/reports/150710A/
              CAIA-TR-150710A.pdf>.

   [CODEL2012]
              Nichols, K. and V. Jacobson, "Controlling Queue Delay",
              July 2012, <http://queue.acm.org/detail.cfm?id=2209336>.

   [I-D.ABE]  Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
              "TCP Alternative Backoff with ECN (ABE)", Internet-draft,
              IETF work-in-progress draft-khademi-tcpm-
              alternativebackoff-ecn-00, May 2016.

   [I-D.AQM-ECN-benefits]
              Fairhurst, G. and M. Welzl, "The Benefits of using
              Explicit Congestion Notification (ECN)", Internet-draft,



Khademi, et al.         Expires December 2, 2016                [Page 8]


Internet-Draft                ECN-response                      May 2016


              IETF work-in-progress draft-ietf-aqm-ecn-benefits-08,
              November 2015.

   [I-D.CUBIC]
              Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
              R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
              Internet-draft, IETF
              work-in-progress draft-ietf-tcpm-cubic-01, January 2016.

   [I-D.CoDel]
              Nichols, K., Jacobson, V., McGregor, V., and J. Iyengar,
              "Controlled Delay Active Queue Management", Internet-
              draft, IETF work-in-progress draft-ietf-aqm-codel-03,
              March 2016.

   [I-D.PIE]  Pan, R., Natarajan, P., Baker, F., White, G., VerSteeg,
              B., Prabhu, M., Piglione, C., and V. Subramanian, "PIE: A
              Lightweight Control Scheme To Address the Bufferbloat
              Problem", Internet-draft, IETF
              work-in-progress draft-ietf-aqm-pie-07, April 2016.

   [I-D.ietf-tcpm-accurate-ecn]
              Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
              Accurate ECN Feedback in TCP",
              draft-ietf-tcpm-accurate-ecn-00 (work in progress),
              December 2015.

   [I-D.ietf-tcpm-dctcp]
              Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P.,
              and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
              Control for Datacenters", draft-ietf-tcpm-dctcp-01 (work
              in progress), November 2015.

   [ICC2002]  Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior
              with Explicit Congestion Notification (ECN)", IEEE
              ICC 2002, New York, New York, USA, May 2002,
              <http://dx.doi.org/10.1109/ICC.2002.997262>.

   [PAM2015]  Trammell, B., Kuhlewind, M., Boppart, D., Learmonth, I.,
              Fairhurst, G., and R. Scheffenegger, "Enabling Internet-
              wide Deployment of Explicit Congestion Notification",
              Proceedings of the 2015 Passive and Active Measurement
              Conference, New York, March 2015,
              <http://ecn.ethz.ch/ecn-pam15.pdf>.

   [RFC7713]  Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
              Concepts, Abstract Mechanism, and Requirements", RFC 7713,
              DOI 10.17487/RFC7713, December 2015,



Khademi, et al.         Expires December 2, 2016                [Page 9]


Internet-Draft                ECN-response                      May 2016


              <http://www.rfc-editor.org/info/rfc7713>.

   [WWDC2015]
              Lakhera, P. and S. Cheshire, "Your App and Next Generation
              Networks", Apple Worldwide Developers Conference 2015, San
              Francisco, USA, June 2015,
              <https://developer.apple.com/videos/wwdc/2015/?id=719>.


Authors' Addresses

   Naeem Khademi
   University of Oslo
   PO Box 1080 Blindern
   Oslo,   N-0316
   Norway

   Email: naeemk@ifi.uio.no


   Michael Welzl
   University of Oslo
   PO Box 1080 Blindern
   Oslo,   N-0316
   Norway

   Email: michawe@ifi.uio.no


   Grenville Armitage
   Centre for Advanced Internet Architectures
   Swinburne University of Technology
   PO Box 218
   John Street, Hawthorn
   Victoria,   3122
   Australia

   Email: garmitage@swin.edu.au


   Godred Fairhurst
   University of Aberdeen
   School of Engineering, Fraser Noble Building
   Aberdeen,   AB24 3UE
   UK

   Email: gorry@erg.abdn.ac.uk




Khademi, et al.         Expires December 2, 2016               [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/