TCP Alternative Backoff with ECN (ABE)
draft-khademi-alternativebackoff-ecn-00

Network Working Group                                         N. Khademi
Internet-Draft                                                  M. Welzl
Updates: 3168 (if approved)                           University of Oslo
Intended status: Experimental                                G. Armitage
Expires: January 1, 2016                         Swinburne University of
                                                              Technology
                                                            G. Fairhurst
                                                  University of Aberdeen
                                                           June 30, 2015

                 TCP Alternative Backoff with ECN (ABE)
                draft-khademi-alternativebackoff-ecn-00

Abstract

   This memo updates the TCP sender-side reaction to a congestion
   notification received via Explicit Congestion Notification (ECN).
   The updated method is less conservative than the TCP reaction in
   response to loss.  The intention is to achieve good throughput when
   the queue at the bottleneck is smaller than the bandwidth-delay-
   product of the connection.  This is more likely when an Active Queue
   Management (AQM) mechanism has ECN-marked a packet than when a packet
   was lost.  Future versions of this document will discuss SCTP as well
   as other transports using ECN.

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 January 1, 2016.

Copyright Notice

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

Khademi, et al.          Expires January 1, 2016                [Page 1]
Internet-Draft                     ABE                         June 2015

   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.  Updating the Sender-side ECN Reaction . . . . . . . . . . . . . 3
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5

Khademi, et al.          Expires January 1, 2016                [Page 2]
Internet-Draft                     ABE                         June 2015

1.  Introduction

   Explicit Congestion Notification (ECN) is specified in [RFC3168].
   This allows a network device that uses Active Queue Management (AQM)
   to CE-mark rather than drop ECN-capable packets when incipient
   congestion is detected.

   When an ECN-capable transport is used over a path that supports ECN,
   it provides the opportunity for flows to improves 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.
   Consequently, a non-ECN enabled standard TCP flow using this reaction
   needs significant queue space: it can only fully utilize a bottleneck
   when the length of the link queue (or the AQM dropping threshold) is
   at least the bandwidth-delay product of the flow.  CUBIC can fully
   utilize a link with a smaller queue because it multiplies the current
   cwnd with 0.8 in response to packet loss [ID.CUBIC] (since kernel
   version 2.6.25 (2008), the Linux implementation uses a value of 0.7).
   In case of a DropTail (FIFO) queue without AQM, this increases the
   risk of creating a standing queue [CODEL2012].

   Devices implementing AQM should be the only source of marking for
   packets from ECN-capable senders.  AQM mechanisms typically strive to
   maintain a small queue length, regardless of the bandwidth-delay
   product of a flows passing through them.  Receipt of a CE-mark
   therefore indicates that reacting less conservatively would be
   appropriate.

   Results reported in [ABE-paper] show significant benefits (improved
   throughput, resulting in reduced completion times for short flows)
   when reacting to ECN-Echo by multiplying cwnd and sstthresh with a
   value in the range [0.7..0.85] rather than 0.5.

2.  Updating the Sender-side ECN Reaction

   This document specifies an updated TCP reaction to the receipt of CE-
   marked packets.

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

Khademi, et al.          Expires January 1, 2016                [Page 3]
Internet-Draft                     ABE                         June 2015

   "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 this text to:

   "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
   induce a less conservative reaction than loss: the TCP source
   multiplies the congestion window 'cwnd' with 0.8 and reduces the slow
   start threshold 'ssthresh'."

3.  Acknowledgements

   The authors were part-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
   contributions to [ABE-paper]: Chamil Kulatunga, David Ros, Stein
   Gjessing, Sebastian Zander.

4.  IANA Considerations

   XX RFC ED - PLEASE REMOVE THIS SECTION XXX

   This memo includes no request to IANA.

5.  Security Considerations

   This document describes a change to TCP congestion control that can
   make a TCP sender more aggressive than flows using RFC 3819.  This
   could lead to an unfair allocation in rates at a bottleneck.  Similar
   unfairness is also exhibited by other congestion control mechanisms
   that have been in use in the Internet for many years (e.g.  Cubic
   [ID.CUBIC]).

   XXX This section to be completed XXX.

Khademi, et al.          Expires January 1, 2016                [Page 4]
Internet-Draft                     ABE                         June 2015

6.  References

6.1.  Normative References

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, September 2009.

6.2.  Informative References

   [ABE-paper]
              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, July 2015 http://caia.swin.edu.au/reports/
              150710A/CAIA-TR-150710A.pdf, NOTE: this document may not
              be available at draft submission date.           We will
              do our best to make it available as soon as possible, and
              definitely before IETF-93.

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

   [I-D.AQM-ECN-benefits]
              Fairhurst, G. and M. Welzl, "The Benefits of using
              Explicit Congestion Notification (ECN)", Internet-draft,
              IETF work-in-progress draft-ietf-aqm-ecn-benefits-05,
              June 2015.

   [ID.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-00, June 2015.

Khademi, et al.          Expires January 1, 2016                [Page 5]
Internet-Draft                     ABE                         June 2015

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 January 1, 2016                [Page 6]