Internet DRAFT - draft-stewart-tsvwg-qsp
draft-stewart-tsvwg-qsp
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]
