A Mechanism for ECN Path Probing and Fallback
draft-kuehlewind-tcpm-ecn-fallback-00

TCPM Working Group                                         M. Kuehlewind
Internet-Draft                                   University of Stuttgart
Intended status: Experimental                                B. Trammell
Expires: January 03, 2014                                     ETH Zurich
                                                           July 02, 2013

             A Mechanism for ECN Path Probing and Fallback
               draft-kuehlewind-tcpm-ecn-fallback-00.txt

Abstract

   Explicit Congestion Notification (ECN) is a TCP/IP extension that is
   widely implemented but hardly used due to the perceived unusablilty
   of ECN on many paths through the Internet caused by ECN-ignorant
   routers and middleboxes.  This document specifies an ECN probing and
   fall-back mechanism in case ECN has be successfully negotiated
   between two connection endpoints, but might not be usable on the
   path.

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 03, 2014.

Copyright Notice

   Copyright (c) 2013 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

Kuehlewind & Trammell   Expires January 03, 2014                [Page 1]
Internet-Draft                ECN Fallback                     July 2013

   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.

1.  Introduction

   The deployment of Explicit Congestion Notification (ECN) [RFC3168]
   and AQM would arguably improve end-to-end performance in the
   Internet, by providing a congestion signal to the transport layer
   without relying on queue tail drop and packet loss.  However, though
   ECN has been standardized since 2000, implementation and deployment
   have lagged significantly, in part due to the perceived unusablilty
   of ECN on many paths through the Internet caused by ECN-ignorant
   routers and middleboxes.

   Recent research by the authors [KuNeTr13] has shown accelerating
   deployment of ECN-capable servers in the Internet, due to the
   deployment of TCP stacks for which ECN is enabled by default.  In
   addition, ECN is usable end-to-end on the vast majority of paths
   measured in this study: that is, a Congestion Experienced mark will
   cause a ECN Echo on the associated ACK.  However, there still exist a
   non-negligible number of paths on which a successfully negotiated
   usage of ECN will not result in a connection on which congestion will
   be correctly echoed, or worse, leads to the loss of packets with CE
   or ECE set.

   This document presents an experimental, in-band, runtime method for
   determining the usability of ECN by a given traffic flow, based on
   the active measurement method described in [KuNeTr13].  If ECN is
   successfully negotiated but found by this method to be unusable, it
   can be disabled on subsequent packets in the flow in order to avoid
   connectivity problems caused by ECN-unusability on the path.

2.  ECN Path Capability Probing

   A TCP sender can determine whether or not its path to the receiver is
   usable for ECN using the procedure detailed below.

   1.  The sender attempts to negotiate ECN usage as per Section 6.1.1
       of [RFC3168].  If ECN is not successfully negotiated, the
       procedure ends, and ECN is not used for the duration of the
       connection.

   2.  The sender disables the normal usage of ECN for the duration of
       the procedure, as the ECN codepoints are used for path probing.
       This means all segments are sent with the Non-ECN-Capable
       codepoint during this procedure unless otherwise stated.
       Moreover, the sender will only take loss as a congestion signal

Kuehlewind & Trammell   Expires January 03, 2014                [Page 2]
Internet-Draft                ECN Fallback                     July 2013

       and will not react with window reductions to the ECN-Echo (ECE)
       feedback signal from the receiver during this procedure.

   3.  The sender sets the Non-ECN-Capable codepoint in the IP header
       until it has completed sending the first N segments, where N is
       the size of the initial congestion window.  Loss is used to
       discover congestion for these segments.

   4.  The next three segments sent consist of the "CE probe": three
       segments are sent with the Congestion Experienced codepoint set.

   5.  If all three of the CE probe segments are lost and must be
       retransmitted, the path is deemed not ECN-usable and the sender
       falls back as in Section 3.

   6.  If the ECE flag is not set on the ACK segment(s) sent by the
       receiver acknowledging the CE probe segments, the path may or may
       not be usable, as that there might be middleboxes/gateways that
       (arguably correctly) clear CE on segments from end hosts, because
       they assume that congestion can not have occurred up to this
       point on the path.  In this case, the sender may continue using
       ECN, because while it may not work for detecting congestion, the
       use of ECN does not negatively affect connectivity.  Note that
       this behavior can be more precisely detected using ECN Nonce
       [RFC3540].

   7.  While the sender does not reduce the congestion window for the
       ECE segment(s) sent for the CE probe segments, it does set CWR on
       the subsequent segment sent.

   8.  If no fallback has occurred by the time the ACK of the final CE
       probe segment is received, the path is deemed ECN usable, and the
       sender ends the probing procedure and proceeds to use ECN
       normally as in [RFC3168].

   As the probing begins after all the segments in the initial
   congestion window have been sent, it requires more than an initial
   congestion window plus 6 segments (3 CE probe + 3 duplicated ACKs) of
   available data to send.  As this information is only available at the
   higher layer, a configuration option per connection should be
   provided to dis/enable ECN as well as ECN probing.  Otherwise, ECN
   should not be enabled for such short flows while using this
   procedure.

3.  ECN Fallback

   If ECN is found to be unusable on a given flow by path capability
   probing as in Section 2 above, the sender simply stops setting any

Kuehlewind & Trammell   Expires January 03, 2014                [Page 3]
Internet-Draft                ECN Fallback                     July 2013

   ECN-Capable-Transport codepoint on subsequent packets in the flow.
   The receiver MUST, however, still set ECE on any ACK for a packet
   with CE set.  Note that this behavior is consistent with section
   6.1.1 of [RFC3168].

   A sender may keep a cache of paths found to be unusable for ECN and
   disable ECN for subsequent connections on a per-destination basis.
   In this case, the reciever should periodically (i.e., on the order of
   hours or days) expire these cache entries to cause re-probing to
   occur in order to account for routing changes in the network.

   [EDITOR'S NOTE: what to do on RTO?]

4.  Discussion

   [EDITOR'S NOTE: need to think about how this would interact with
   conex; an analysis comparing the delay caused by path probing as
   opposed to the delay caused by ECN failure would be interesting.]

   [EDITOR'S NOTE: initial implementation results go here?.]

5.  Security Considerations

   [FIXME: we'll have to explore attacks against this mechanism which
   could affect network or connection stability, so the following is
   wrong...]

   This document has no security considerations.

6.  IANA Considerations

   This document has no IANA considerations.

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, September 2001.

7.2.  Informative References

   [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
              Congestion Notification (ECN) Signaling with Nonces", RFC
              3540, June 2003.

   [KuNeTr13]

Kuehlewind & Trammell   Expires January 03, 2014                [Page 4]
Internet-Draft                ECN Fallback                     July 2013

              Kuehlewind, M., Neuner, S., and B. Trammell, "On the state
              of ECN and TCP Options on the Internet", Mar 2013.

              (In LNCS 7799, Proceedings of PAM 2013, Hong Kong)

Authors' Addresses

   Mirja Kuehlewind
   University of Stuttgart
   Pfaffenwaldring 47
   70569 Stuttgart
   Germany

   Email: mirja.kuehlewind@ikr.uni-stuttgart.de

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   Email: trammell@tik.ee.ethz.ch

Kuehlewind & Trammell   Expires January 03, 2014                [Page 5]