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

Versions: 00 01

tcpm                                                  M. Kuehlewind, Ed.
Internet-Draft                                   University of Stuttgart
Intended status: Experimental                           R. Scheffenegger
Expires: January 14, 2013                                   NetApp, Inc.
                                                           July 13, 2012


                  Accurate ECN Feedback Option in TCP
              draft-kuehlewind-tcpm-accurate-ecn-option-01

Abstract

   This document specifies an TCP option to get accurate Explicit
   Congestion Notification (ECN) feedback from the receiver.  ECN is an
   IP/TCP mechanism where network nodes can mark IP packets instead of
   dropping them to indicate congestion to the end-points.  An ECN-
   capable receiver will feedback this information 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).  Recently new TCP
   mechanisms like ConEx or DCTCP need more accurate feedback
   information in the case where more than one marking is received in
   one RTT.  This TCP extension can be used in addition to the classic
   ECN as well as with a more accurate ECN scheme recently proposed
   which reuses the ECN bit in the TCP header.

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 14, 2013.

Copyright Notice

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



Kuehlewind & Scheffenegger  Expires January 14, 2013            [Page 1]


Internet-Draft     Accurate ECN Feedback Option in TCP         July 2012


   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.  Overview ECN and ECN Nonce in IP  . . . . . . . . . . . . . 3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Negotiation of Accurate ECN feedback  . . . . . . . . . . . . . 4
   3.  Accurate ECN (AccECN) feedback Option Specification . . . . . . 5
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7



























Kuehlewind & Scheffenegger  Expires January 14, 2013            [Page 2]


Internet-Draft     Accurate ECN Feedback Option in TCP         July 2012


1.  Introduction

   Explicit Congestion Notification (ECN) [RFC3168] is an IP/TCP
   mechanism where network nodes can mark IP packets instead of dropping
   them to indicate congestion to the end-points.  An ECN-capable
   receiver will feedback this information 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).  Recently proposed mechanisms
   like Congestion Exposure (ConEx) or DCTCP [Ali10] need more accurate
   feedback information in case when more than one marking is received
   in one RTT.

   This documents specifies an TCP option to provide more than one ECN
   feedback signal per RTT.  This modification does not obsolete
   [RFC3168].  This TCP extension can be used in addition to the classic
   ECN as well as in addition to more accurate ECN scheme recently
   proposed which reuses the ECN bits in the TCP header for the same
   purpose than this extension --- more accurate ECN feedback (see
   [I-D.kuehlewind-conex-accurate-ecn]).  Note that a new TCP extension
   can experience deployment problems by middleboxes dropping unknown
   options.  Thus the ECN feedback in the TCP header is still needed to
   ensure ECN feedback.  Moreover, this option will increase the header
   length for all kind of TCP packets which can cause additional load in
   case of severe congestion (on the feedback channel).

1.1.  Overview ECN and ECN Nonce in IP

   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.  An ECN
   sender can set one or the other bit to indicate an ECN-capable
   transport (ETC) which results in two signals --- ECT(0) and
   respectively ECT(1).  A network node can set both bits simultaneously
   when it experiences congestion.  When both bits are set the packets
   is regarded as "Congestion Experienced" (CE).

   ECN-Nonce [RFC3540] is an optional addition to ECN that is used to
   protects the TCP sender against accidental or malicious concealment
   of marked or dropped packets.  With ECN-Nonce a nonce sum is maintain
   that counts the occurrence of ECT(1) packets.

1.2.  Requirements Language

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

   We use the following terminology from [RFC3168] and [RFC3540]:




Kuehlewind & Scheffenegger  Expires January 14, 2013            [Page 3]


Internet-Draft     Accurate ECN Feedback Option in TCP         July 2012


   The ECN field in the IP header:

             CE: the Congestion Experienced codepoint; and

             ECT(0)/ECT(1): either one of the two ECN-Capable Transport
             codepoints.

   In this document, we will call the ECN feedback scheme as specified
   in [RFC3168] the 'classic ECN'.  A 'congestion mark' is defined as an
   IP packet where the CE codepoint is set.


2.  Negotiation of Accurate ECN feedback

   As there is only limited space in the TCP Options, particularly
   during the initial three-way handshake, an abbreviated Option is used
   to negotiate for Accurate ECN feedback.  This option also initiates
   all counters to an initial value of zero at the receiving side.


   TCP Accurate ECN Option Negotiation:

      Kind: TBD

      Length: 2 bytes

     +------+-----+
     | Kind |  2  |
     +------+-----+
        1      1


          Figure 1: Accurate ECN feedback TCP option negotiation

   This abbreviated option is only valid in a <SYN> or <SYN,ACK>
   segment, during a three way handshake.  The negotiation follows the
   same procedure as with other TCP options, i.e.  SACK.  A TCP sender
   MAY send the accurate ECN feedback negotiation option in an initial
   SYN segment and MAY send a more accurate ECN option (see Section 3)
   in other segments only if it received this option negotiation in the
   initial <SYN> segment or <SYN,ACK> for the connection.  A TCP
   receiver MAY send an <SYN,ACK> segment with the accurate ECN feedback
   negotiation option in response to a received accurate ECN feedback
   negotiation option in the <SYN>.  If both ends indicate that they
   support Accurate ECN (AccECN) feedback, the AccECN option SHOULD be
   used in any subsequent TCP segment.  A TCP sender or receiver MUST
   only negotiate for the AccECN option if ECN is negotiated as well.




Kuehlewind & Scheffenegger  Expires January 14, 2013            [Page 4]


Internet-Draft     Accurate ECN Feedback Option in TCP         July 2012


3.  Accurate ECN (AccECN) feedback Option Specification

   A TCP receiver, that provides Accurate ECN feedback, will maintain a
   counter for the number of ECT(0), ECT(1), CE, non-ECT marked and lost
   packets as well as the cumulative number of bytes of CE marked
   packets.  The TCP option to provide the Accurate ECN (AccECN)
   feedback to the sender will echo these counters.

TCP Accurate ECN Option:

  Kind: TBD (same as above)

  Length: 12 bytes

 +------+------+---------+---------+-------+-------+-------+-----------+
 | Kind |  12  | ECT(0)  | ECT(1)  |  CE   |non-ECT| loss  |CE in bytes|
 +------+------+---------+---------+-------+-------+-------+-----------+
    1      1        2         2        1       1       1         3


                Figure 2: Accurate ECN feedback TCP option

   TCP anyway provides a mechanism to detect loss as loss should always
   be assumes as a strong signal for congestion and TCP congestion
   control reacts on loss.  If TCP SACK is not available, the exact
   number of losses is not known.  Moreover, the TCP loss detection
   (incl.  SACK) is done in bytes and not in number of packets.  The
   number of lost packets can be used by the sender to calculate the ECN
   Nonce sum more exactly.

   The same feedback information are proposed for the (ECN) feedback in
   RTP (see [I-D.ietf-avtcore-ecn-for-rtp].

   As TCP is a bi-directional protocol, this option can be used in both
   directions.  With the reception of every data segment at least one of
   the counters changes (ETC(0) or ETC(1)).  The AccECN option SHOULD be
   included in every ACK to ensure the reception of the ECN feedback at
   the sender in case of ACK loss.  To reduce network load the AccECN
   option MAY not be send in every ACK, e.g. only in very second ACK (if
   ACKs are sent very frequently).

   In general it is possible that any of the counters wraps around.  In
   this case the information might get corrupted if e.g. for any reason
   only one ACK per RTT is sent and more than 256 CE marks occur in one
   RTT.  For this case it MUST be ensured, that at least three ACKs/
   segments with the AccECN option have been sent prior to the counter
   experiencing an wrap around.  Whenever an AccECN Option is received
   with smaller counter value than in the previous one and the



Kuehlewind & Scheffenegger  Expires January 14, 2013            [Page 5]


Internet-Draft     Accurate ECN Feedback Option in TCP         July 2012


   respective ACK acknowledges new data, a wrap around MUST be assumed.


4.  Acknowledgements


5.  IANA Considerations

   TBD


6.  Security Considerations

   TBD


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

7.2.  Informative References

   [Ali10]    Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel,
              P., Prabhakar, B., Sengupta, S., and M. Sridharan, "DCTCP:
              Efficient Packet Transport for the Commoditized Data
              Center", Jan 2010.

   [I-D.briscoe-tsvwg-re-ecn-tcp]
              Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith,
              "Re-ECN: Adding Accountability for Causing Congestion to
              TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-09 (work in
              progress), October 2010.

   [I-D.ietf-avtcore-ecn-for-rtp]
              Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
              and K. Carlberg, "Explicit Congestion Notification (ECN)
              for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-08 (work



Kuehlewind & Scheffenegger  Expires January 14, 2013            [Page 6]


Internet-Draft     Accurate ECN Feedback Option in TCP         July 2012


              in progress), May 2012.

   [I-D.kuehlewind-conex-accurate-ecn]
              Kuehlewind, M. and R. Scheffenegger, "Accurate ECN
              Feedback in TCP", draft-kuehlewind-conex-accurate-ecn-01
              (work in progress), October 2011.


Authors' Addresses

   Mirja Kuehlewind (editor)
   University of Stuttgart
   Pfaffenwaldring 47
   Stuttgart  70569
   Germany

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


   Richard Scheffenegger
   NetApp, Inc.
   Am Euro Platz 2
   Vienna,   1120
   Austria

   Phone: +43 1 3676811 3146
   Email: rs@netapp.com
























Kuehlewind & Scheffenegger  Expires January 14, 2013            [Page 7]


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