[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03

Network Working Group                                         R. Stewart
Internet-Draft                                            Adara Networks
Intended status: Standards Track                               M. Tuexen
Expires: July 19, 2014                  Muenster Univ. of Appl. Sciences
                                                        January 15, 2014


                            Quick Start Plus
                     draft-stewart-tsvwg-qsp-03.txt

Abstract

   This document describes an extension to Quick Start including the
   missing Stream Control Transmission Protocol (SCTP) QuickStart chunk
   types and procedures so that SCTP may also use the QuickStart
   extension.

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 July 19, 2014.

Copyright Notice

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



Stewart & Tuexen          Expires July 19, 2014                 [Page 1]


Internet-Draft                     QSP                      January 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Data Format . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Quick Start Extended IP option  . . . . . . . . . . . . .   3
     4.2.  Quick Start Echo (133) for SCTP . . . . . . . . . . . . .   4
   5.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Quick Start Added Procedures  . . . . . . . . . . . . . .   5
     5.2.  SCTP QSE Receiver Procedures  . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative references  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informational References  . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   QuickStart [RFC4782] was introduced as an expermental RFC in 2007.
   This document attempts to address several issues in QuickStart
   including granularity of request, active router participation in
   quick start besides setup, and the lack of QuickStart for SCTP
   [RFC4960].  In order to address these issues this document specifies:

   *  An extended format for QuickStart that allows a more finegrained
      rate to be specified by the router.

   *  A new code QuickStart Function Code to allow a router to initiate
      a rate change to a transport endpoint.

   *  Chunk format's and handling procedures for SCTP's use of
      QuickStart.

   Note that with few exceptions this document does not change the
   general procedures laid out in [RFC4782] readers unfamiliar with that
   document are encouraged to read it before reading this document.

2.  Conventions

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






Stewart & Tuexen          Expires July 19, 2014                 [Page 2]


Internet-Draft                     QSP                      January 2014


3.  Terminology

   All integer fields defined in this document MUST be transmitted in
   network byte order, unless otherwise stated.

4.  Data Format

4.1.  Quick Start Extended IP option


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Option      |  Length=12    | Func. | Rate  |   QS TTL      |
       |               |               | 1100  | Upper |               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        QS Nonce                           |R|1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Rate Lower                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option: 8 bits

      As defined in [RFC4782].

   Length: 8 bits

      Contains the value 12 to indicate the new extended option.  If the
      field contains the value 8, then the shorter classic version of
      the rate is used per [RFC4782].

   Function: 4 bits

      Contains the values 0000 or 1000 as defined in [RFC4782] or the
      new value 1100 which indicates that a router is adjusting the rate
      and should be treated the same as a request 0000 (i.e. echoed by
      the destination endpoint in an appropriate transport option back
      to the sender of the packet).

   Rate: 4 bits

      In the extended form, these four bits are the upper bits of the
      rate being requested (or set).  The combined rate field yeilds a
      36 bit integer indicating the number of kilobits per second that
      is being requested or authorized.

   QS TTL: 8 bits



Stewart & Tuexen          Expires July 19, 2014                 [Page 3]


Internet-Draft                     QSP                      January 2014


      As defined in [RFC4782].

   QS Nonce: 30 bits

      As defined in [RFC4782].

   Reserved: 1 bits

      This bit is reserved and SHOULD be set to 0 on transmit and
      ignored upon reception.

   E bit: 1 bits

      This bit is set to 1 to indicate that the extended form of the
      option is present.  This can also be verified by confirming that
      the length field is set to 12.

   Rate Lower: 32 bits

      This field holds the lower 32 bits of the rate.  This field is
      combined with the 4 bit Rate Upper field to yeild a 36 bit rate in
      kilo-bits per second.

4.2.  Quick Start Echo (133) for SCTP


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Chunk Type=133| Flags=00000000|    Chunk Length = 12 or 16    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       QuickStart Option as copied from IP options field       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Chunk Flags: 8 bits

      Set to all zeros on transmit and ignored on receipt.

      This parameter contains the exact copy of the IP options field
      received on the incoming packet that caused this chunk to be sent.
      The chunk is normally added to the next outgoing packet (often
      times a SACK or DATA chunk).








Stewart & Tuexen          Expires July 19, 2014                 [Page 4]


Internet-Draft                     QSP                      January 2014


5.  Procedures

5.1.  Quick Start Added Procedures

   Procedures for the extended form of Quickstart are identical to those
   defined in [RFC4782].  The only two differences are as follows.

   First when presented with the extended version of QuickStart the
   receiver of the IP option must combine the two Rate fields defined to
   extract the rate information being requested (or authorized).  The
   handling of the rate by a router is still done as previously, i.e.
   examine the rate, decrement the TTL and possibly lower the rate
   (these procedures do not change and remain the same).  For an
   endpoint receiving a QuickStart option in the extended form, the
   transport option is also increased by four bytes and the entire
   option is copied and sent to the peer endpoint if the arriving
   Function Code is either 0000 or the new 1100.

   Secondly both endpoints and routers may receive the new function code
   1100.  When such a function code arrives, it should be treated the
   same as a function code 0000 in classic QuickStart i.e. it is treated
   as a rate request.  If a router is receiving this code, it again
   looks to see if it needs to lower the rate, decrements the TTL and
   possibly updates the rate and nonce fields.  Transport endpoints
   receiving this Function code echo the complete 12 byte option within
   there transport specific manner to the peer transport endpoint (i.e.
   the sender of the arriving packet that contains the Quickstart
   option).

   The sender of the 1100 function code, however is not a transport
   endpoint requesting a rate.  Instead this option may be inserted by
   any router on the path to adjust the rate of a flow passing through
   it.  The router MUST have flow state and MUST have previously seen a
   QuickStart Rate Request (Func 0000) and a subsequent Quickstart Rate
   Report (Func 1000) from that flow before inserting this option.  In
   other words the router MUST know that the flow supports QuickStart
   and that all downstream routers also support QuickStart.  Furthermore
   the router must know if the extended form of QuickStart is in use by
   the flow or as an alternative use the non-extended format.  This is
   determined based on if the initial QuickStart Rate Request which was
   received is in the extended format (aka 12 bytes with the E bit set)
   or in the old original format (aka 8 bytes with two reserved bits set
   to zero).

   When a Router inserts the 1100 funtion code, the router MUST use the
   last saved QS Nonce and TTL's that were seen when the flow originally
   sent its QuickStart Rate Request.  The router MUST adjust the TTL so
   that the difference between the original packets Rate Requests TTL is



Stewart & Tuexen          Expires July 19, 2014                 [Page 5]


Internet-Draft                     QSP                      January 2014


   present in the packet being inserted.  The router should also adjust
   the proper field in the nonce per [RFC4782] to reflect which rate
   range the router was adjusting the flow to.  This allows the endpoint
   to validate both the Nonce and the TTL in the same manner in which it
   would if it had sent the IP option as a rate request.

5.2.  SCTP QSE Receiver Procedures

   Proceedures for SCTP are identical with those associated with TCP and
   can be found within [RFC4782].  The key difference is the method in
   which the Response Option is carried in SCTP.  SCTP does not use
   options, instead a new chunk is defined that carries either the
   traditional QuickStart option, or the extended form.

   At SCTP association startup the two endpoint exchange an INIT and
   INIT-ACK chunk as defined in [RFC4960].  During this exchange both
   endpoints MUST include a Supported Extensions chunk as defined in
   [RFC5061].  Both endpoints MUST indicate support for the new QSE
   chunk type.  If both endpoints do not indicate this then the use of
   QuickStart is not enabled for this SCTP association.  If both
   endpoints do indicate the support of QuickStart, then the next packet
   out (usually the Cookie-Echo or Cookie-Ack) SHOULD include an IP
   option requesting a rate.  Note the endpoint SHOULD use the extended
   format.  The fields are initialized the same as defined in [RFC4782]
   with the exception that if the extended format is used, the rate is
   an exact 36 bit value representing the requested rate.

   Upon receiving a packet with an IP option indicating either Function
   0000 or Function 1100, the SCTP endpoint MUST include in the next
   outgoing packet (most likely a SACK or DATA chunk) the QSE chunk with
   a copy of the IP option that arrived.

   When receiving a QSE chunk, an endpoint follows the procedures in
   [RFC4960] validating the TTL difference and the nonce before setting
   the local cwnd to the new rate.  Any validation failure, for example
   if there is a TTL difference indicating that not all routers
   participated in the QuickStart exchange, then the endpoint MUST NOT
   use the QuickStart procedures to change the cwnd.

   Note that because IP options are not always passed correctly by
   routers and middle boxes, an endpoint SHOULD be prepared to disable
   the use of QuickStart if the initial transmissions of the IP option
   is not acknowledged (e.g. the endpoint sends a COOKIE-ECHO with the
   QS IP option and the retransmit timer fires due to the lack of a
   COOKIE-ACK response from the endpoint).






Stewart & Tuexen          Expires July 19, 2014                 [Page 6]


Internet-Draft                     QSP                      January 2014


6.  Security Considerations

   [RFC4782] defines the security considerations for Quickstart.  These
   same consideration that are described for TCP are applicable to this
   document.

7.  IANA Considerations

   Nothing requested.

8.  Acknowledgements

9.  References

9.1.  Normative references

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

   [RFC4782]  Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
              Start for TCP and IP", RFC 4782, January 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061, September
              2007.

9.2.  Informational References

   [RFC2481]  Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
              Congestion Notification (ECN) to IP", RFC 2481, January
              1999.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

Authors' Addresses









Stewart & Tuexen          Expires July 19, 2014                 [Page 7]


Internet-Draft                     QSP                      January 2014


   Randall R. Stewart
   Adara Networks
   Chapin, SC  29036
   USA

   Email: randall@lakerest.net


   Michael Tuexen
   Muenster University of Applied Sciences
   Stegerwaldstr. 39
   48565 Steinfurt
   Germany

   Email: tuexen@fh-muenster.de




































Stewart & Tuexen          Expires July 19, 2014                 [Page 8]


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