draft-ietf-tsvwg-quickstart-04.txt   draft-ietf-tsvwg-quickstart-05.txt 
Internet Engineering Task Force S. Floyd Internet Engineering Task Force S. Floyd
INTERNET-DRAFT M. Allman INTERNET-DRAFT M. Allman
draft-ietf-tsvwg-quickstart-04.txt ICIR draft-ietf-tsvwg-quickstart-05.txt ICIR
Expires: December 2006 A. Jain Expires: January 2007 A. Jain
F5 Networks F5 Networks
P. Sarolahti P. Sarolahti
Nokia Research Center Nokia Research Center
Quick-Start for TCP and IP Quick-Start for TCP and IP
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
skipping to change at page 1, line 34 skipping to change at page 1, line 34
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2006. This Internet-Draft will expire on January 2007.
Abstract Abstract
This document specifies an optional Quick-Start mechanism for This document specifies an optional Quick-Start mechanism for
transport protocols, in cooperation with routers, to determine an transport protocols, in cooperation with routers, to determine an
allowed sending rate at the start and at times in the middle of a allowed sending rate at the start and at times in the middle of a
data transfer (e.g., after an idle period). While Quick-Start is data transfer (e.g., after an idle period). While Quick-Start is
designed to be used by a range of transport protocols, in this designed to be used by a range of transport protocols, in this
document we only specify its use with TCP. Quick-Start is designed document we only specify its use with TCP. Quick-Start is designed
to allow connections to use higher sending rates when there is to allow connections to use higher sending rates when there is
significant unused bandwidth along the path and the sender and all significant unused bandwidth along the path and the sender and all
of the routers along the path approve the Quick-Start Request. of the routers along the path approve the Quick-Start Request.
As this document describes, environments where Quick-Start requests This document describes many paths where Quick-Start requests would
would not be approved include paths with routers, IP tunnels, MPLS not be approved. These paths include all paths containing routers,
paths, and the like that do not support Quick-Start, or paths with IP tunnels, MPLS paths, and the like that do not support Quick-
routers or middleboxes that drop packets containing IP options. Start. These paths also include paths with routers or middleboxes
Quick-Start requests could be difficult to approve over paths that that drop packets containing IP options. Quick-Start requests could
include multi-access layer-two networks. This document also be difficult to approve over paths that include multi-access layer-
describes environments where the Quick-Start process could fail with two networks. This document also describes environments where the
false positives, with the sender incorrectly assuming that the Quick-Start process could fail with false positives, with the sender
Quick-Start request had been approved by all of the routers along incorrectly assuming that the Quick-Start request had been approved
the path. As a result of these concerns, and as a result of the by all of the routers along the path. As a result of these
difficulties and seeming absence of motivation for routers such as concerns, and as a result of the difficulties and seeming absence of
core routers to deploy Quick-Start, Quick-Start is being proposed as motivation for routers such as core routers to deploy Quick-Start,
a mechanism that could be of use in controlled environments, and not Quick-Start is being proposed as a mechanism that could be of use in
as a mechanism that would be intended or appropriate for ubiquitous controlled environments, and not as a mechanism that would be
deployment in the global Internet. intended or appropriate for ubiquitous deployment in the global
Internet.
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Changes from draft-ietf-tsvwg-quickstart-04:
* Reformatted references so that "[RFC2581, RFC3390]"
is instead "([RFC2581], [RFC3390])", to eliminate
bug reports from the idnits tool. From feedback
from Dan Romascanu.
* Rephrased beginning of second paragraph in the
Abstract. From feedback from James Polk.
Changes from draft-ietf-tsvwg-quickstart-03: Changes from draft-ietf-tsvwg-quickstart-03:
* Added a discussion of the lower limit of the rate request * Added a discussion of the lower limit of the rate request
of 80 kbps, from feedback from Gorry Fairhurst. of 80 kbps, from feedback from Gorry Fairhurst.
* Added the QS Nonce to the QS Approved Rate. * Added the QS Nonce to the QS Approved Rate.
From feedback from Gorry Fairhurst. From feedback from Gorry Fairhurst.
* Moved the Related Work section to the appendix. * Moved the Related Work section to the appendix.
From feedback from Gorry Fairhurst. From feedback from Gorry Fairhurst.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
1. Introduction 1. Introduction
Each connection begins with a question: "What is the appropriate Each connection begins with a question: "What is the appropriate
sending rate for the current network path?" The question is not sending rate for the current network path?" The question is not
answered explicitly, but each TCP connection determines the sending answered explicitly, but each TCP connection determines the sending
rate by probing the network path and altering the congestion window rate by probing the network path and altering the congestion window
(cwnd) based on perceived congestion. Each TCP connection starts (cwnd) based on perceived congestion. Each TCP connection starts
with a pre-configured initial congestion window (ICW). Currently, with a pre-configured initial congestion window (ICW). Currently,
TCP allows an initial window of between one and four MSS-sized TCP allows an initial window of between one and four MSS-sized
segments [RFC2581, RFC3390]. The TCP connection then probes the segments ([RFC2581], [RFC3390]). The TCP connection then probes the
network for available bandwidth using the slow-start procedure network for available bandwidth using the slow-start procedure
[Jac88, RFC2581], doubling cwnd during each congestion-free round- ([Jac88], [RFC2581]), doubling cwnd during each congestion-free
trip time (RTT). round-trip time (RTT).
The slow-start algorithm can be time-consuming --- especially over The slow-start algorithm can be time-consuming --- especially over
networks with large bandwidth or long delays. It may take a number networks with large bandwidth or long delays. It may take a number
of RTTs in slow-start before the TCP connection begins to fully use of RTTs in slow-start before the TCP connection begins to fully use
the available bandwidth of the network. For instance, it takes the available bandwidth of the network. For instance, it takes
log_2(N) - 2 round-trip times to build cwnd up to N segments, log_2(N) - 2 round-trip times to build cwnd up to N segments,
assuming an initial congestion window of 4 segments. This time in assuming an initial congestion window of 4 segments. This time in
slow-start is not a problem for large file transfers, where the slow-start is not a problem for large file transfers, where the
slow-start stage is only a fraction of the total transfer time. slow-start stage is only a fraction of the total transfer time.
However, in the case of moderate-sized transfers the connection However, in the case of moderate-sized transfers the connection
skipping to change at page 27, line 20 skipping to change at page 27, line 20
determine an appropriate rate.) determine an appropriate rate.)
(2) After an idle period when the transport no longer has a (2) After an idle period when the transport no longer has a
validated estimate of the available bandwidth for this flow. validated estimate of the available bandwidth for this flow.
(An example could be a persistent-HTTP connection when a new (An example could be a persistent-HTTP connection when a new
HTTP request is received after an idle period.) HTTP request is received after an idle period.)
(3) After a host has received explicit indications that one of (3) After a host has received explicit indications that one of
the endpoints has moved its point of network attachment. This the endpoints has moved its point of network attachment. This
can happen due to some underlying mobility mechanism like Mobile can happen due to some underlying mobility mechanism like Mobile
IP [RFC3344, RFC3775]. Some transports, such as SCTP [RFC2960], IP ([RFC3344], [RFC3775]). Some transports, such as SCTP
may associate with multiple IP addresses and can switch [RFC2960], may associate with multiple IP addresses and can
addresses (and, therefore network paths) in mid-connection. If switch addresses (and, therefore network paths) in mid-
the transport has concrete knowledge of a changing network path connection. If the transport has concrete knowledge of a
then the current sending rate may not be appropriate and the changing network path then the current sending rate may not be
transport sender may use Quick-Start to probe the network to see appropriate and the transport sender may use Quick-Start to
if it can send at a higher rate. (Alternatively, traditional probe the network to see if it can send at a higher rate.
slow-start should be used in this case when Quick-Start is not (Alternatively, traditional slow-start should be used in this
available.) case when Quick-Start is not available.)
(4) After an application-limited period when the sender has been (4) After an application-limited period when the sender has been
using only a small amount of its appropriate share of the using only a small amount of its appropriate share of the
network capacity, and has no valid estimate for its fair share. network capacity, and has no valid estimate for its fair share.
In this case, Quick-Start may be an appropriate mechanism to In this case, Quick-Start may be an appropriate mechanism to
determine if the sender can send at a higher rate. For determine if the sender can send at a higher rate. For
instance, consider an application that steadily exchanges low- instance, consider an application that steadily exchanges low-
rate control messages and suddenly needs to transmit a large rate control messages and suddenly needs to transmit a large
amount of data. amount of data.
skipping to change at page 36, line 30 skipping to change at page 36, line 30
congestion window appropriately, and sets up rate-based pacing to be congestion window appropriately, and sets up rate-based pacing to be
used with its initial window. If the Quick-Start Response is not used with its initial window. If the Quick-Start Response is not
valid, then Host B uses TCP's default initial window. In either valid, then Host B uses TCP's default initial window. In either
case, Host B sends a Report of Approved Rate. case, Host B sends a Report of Approved Rate.
5. Quick-Start and IPsec AH 5. Quick-Start and IPsec AH
This section shows that Quick-Start is compatible with IPsec AH This section shows that Quick-Start is compatible with IPsec AH
(Authentication Header). AH uses an Integrity Check Value (ICV) in (Authentication Header). AH uses an Integrity Check Value (ICV) in
the IPsec Authentication Header to verify both message the IPsec Authentication Header to verify both message
authentication and integrity [RFC2402,2402bis]. Changes to the authentication and integrity ([RFC2402], [2402bis]). Changes to the
Quick-Start option in the IP header do not affect this AH ICV. The Quick-Start option in the IP header do not affect this AH ICV. The
tunnel considerations in Section 6 below apply to all IPsec tunnels, tunnel considerations in Section 6 below apply to all IPsec tunnels,
regardless of what IPsec headers or processing are used in regardless of what IPsec headers or processing are used in
conjunction with the tunnel. conjunction with the tunnel.
Because the contents of the Quick-Start option can change along the Because the contents of the Quick-Start option can change along the
path, it is important that these changes not affect the IPsec path, it is important that these changes not affect the IPsec
Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC
2402 requires that unrecognized IPv4 options be zeroed for AH ICV 2402 requires that unrecognized IPv4 options be zeroed for AH ICV
computation purposes, so Quick-Start IP Option data changing en computation purposes, so Quick-Start IP Option data changing en
skipping to change at page 37, line 8 skipping to change at page 37, line 8
indicate whether the option is mutable; the 3rd highest order bit in indicate whether the option is mutable; the 3rd highest order bit in
the IANA-allocated option type has the value 1 to indicate that the the IANA-allocated option type has the value 1 to indicate that the
Quick-Start option data can change en route. RFC 2402 requires that Quick-Start option data can change en route. RFC 2402 requires that
the option data of any such option be zeroed for AH ICV computation the option data of any such option be zeroed for AH ICV computation
purposes. Therefore changes to the Quick-Start option in the IP purposes. Therefore changes to the Quick-Start option in the IP
header do not affect the calculation of the AH ICV. header do not affect the calculation of the AH ICV.
6. Quick-Start in IP Tunnels and MPLS 6. Quick-Start in IP Tunnels and MPLS
This section considers interactions between Quick-Start and IP This section considers interactions between Quick-Start and IP
tunnels, including IPsec [RFC2401,2401bis], IP in IP [RFC2003], GRE tunnels, including IPsec ([RFC2401], [2401bis]), IP in IP [RFC2003],
[RFC2784], and others. This section also considers interactions GRE [RFC2784], and others. This section also considers interactions
between Quick-Start and MPLS [RFC3031]. between Quick-Start and MPLS [RFC3031].
In the discussion, we use TTL Diff, defined earlier as the In the discussion, we use TTL Diff, defined earlier as the
difference between the IP TTL and the Quick-Start TTL, mod 256. difference between the IP TTL and the Quick-Start TTL, mod 256.
Recall that the sender considers the Quick-Start request approved Recall that the sender considers the Quick-Start request approved
only if the value of TTL Diff for the packet entering the network is only if the value of TTL Diff for the packet entering the network is
the same as the value of TTL Diff for the packet exiting the the same as the value of TTL Diff for the packet exiting the
network. network.
Simple tunnels: IP tunnel modes are generally based on adding a new Simple tunnels: IP tunnel modes are generally based on adding a new
skipping to change at page 64, line 29 skipping to change at page 64, line 29
competing best-effort connections. competing best-effort connections.
B. Design Decisions B. Design Decisions
B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
This document has proposed using an IP Option for the Quick-Start This document has proposed using an IP Option for the Quick-Start
Request from the sender to the receiver, and using transport Request from the sender to the receiver, and using transport
mechanisms for the Quick-Start Response from the receiver back to mechanisms for the Quick-Start Response from the receiver back to
the sender. In this section we discuss alternate mechanisms, and the sender. In this section we discuss alternate mechanisms, and
consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols consider whether ICMP ([RFC792], [RFC2463]) or RSVP [RFC2205]
could be used for delivering the Quick-Start Request. protocols could be used for delivering the Quick-Start Request.
B.1.1. ICMP B.1.1. ICMP
Being a control protocol used between Internet nodes, one could Being a control protocol used between Internet nodes, one could
argue that ICMP is the ideal method for requesting a permission for argue that ICMP is the ideal method for requesting a permission for
faster startup from routers. The ICMP header is above the IP faster startup from routers. The ICMP header is above the IP
header. Quick-Start could be accomplished with ICMP as follows: If header. Quick-Start could be accomplished with ICMP as follows: If
the ICMP protocol is used to implement Quick-Start, the equivalent the ICMP protocol is used to implement Quick-Start, the equivalent
of the Quick-Start IP option would be carried in the ICMP header of of the Quick-Start IP option would be carried in the ICMP header of
the ICMP Quick-Start Request. The ICMP Quick-Start Request would the ICMP Quick-Start Request. The ICMP Quick-Start Request would
skipping to change at page 81, line 10 skipping to change at page 81, line 10
Temporary Bandwidth Use: A Temporary codepoint has been proposed to Temporary Bandwidth Use: A Temporary codepoint has been proposed to
indicate that a connection would only use the requested bandwidth indicate that a connection would only use the requested bandwidth
for a single time interval. for a single time interval.
F. Feedback from Bob Briscoe F. Feedback from Bob Briscoe
[B05] is a review of an earlier version of the Quick-Start proposal [B05] is a review of an earlier version of the Quick-Start proposal
that discusses a number of potential problems with Quick-Start, and that discusses a number of potential problems with Quick-Start, and
argues for an alternate approach for policing congestion in networks argues for an alternate approach for policing congestion in networks
using re-feedback [BJCG+05,BJS05]. However, [B05] didn't oppose the using re-feedback ([BJCG+05], [BJS05]). However, [B05] didn't
move to Quick-Start to experimental status as long as its oppose the move to Quick-Start to experimental status as long as its
applicability is made clear. applicability is made clear.
F.1. Potential Deployment Scenarios F.1. Potential Deployment Scenarios
[B05] argues that because the sender's trustworthiness is not [B05] argues that because the sender's trustworthiness is not
necessarily verified, Quick-Start, if it is remain stateless, should necessarily verified, Quick-Start, if it is remain stateless, should
be confined to environments where every source is trusted. Section be confined to environments where every source is trusted. Section
3.2 of [B05] argues that either (1) Quick-Start should be 3.2 of [B05] argues that either (1) Quick-Start should be
recommended for deployment only in trusted environments, or (2) recommended for deployment only in trusted environments, or (2)
Quick-Start could be recommended for deployment also in untrusted Quick-Start could be recommended for deployment also in untrusted
skipping to change at page 86, line 13 skipping to change at page 86, line 13
[RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140.
April 1997. April 1997.
[RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification. RFC 2205, September 1997. Version 1 Functional Specification. RFC 2205, September 1997.
[RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE),
RFC 2409, November 1998. RFC 2409, November 1998.
[RFC2246] T. Dierks and C. Allen, The TLS Protocol, RFC 2246.
[RFC2401] S. Kent and R. Atkinson. Security Architecture for the [RFC2401] S. Kent and R. Atkinson. Security Architecture for the
Internet Protocol. RFC 2401, November 1998. Internet Protocol. RFC 2401, November 1998.
[2401bis] S. Kent and K. Seo, Security Architecture for the Internet [2401bis] S. Kent and K. Seo, Security Architecture for the Internet
Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt, work- Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt, work-
in-progress, March 2005. in-progress, March 2005.
[RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC
2402, November 1998.
[2402bis] S. Kent, IP Authentication Header, internet-draft draft- [2402bis] S. Kent, IP Authentication Header, internet-draft draft-
ietf-ipsec-rfc2402bis-11.txt work-in-progress, March 2005. ietf-ipsec-rfc2402bis-11.txt work-in-progress, March 2005.
[RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased
Initial TCP Window Size. RFC 2415. September 1998. Initial TCP Window Size. RFC 2415. September 1998.
[RFC2416] T. Shepard and C. Partridge. When TCP Starts Up With Four
Packets Into Only Three Buffers. RFC 2416. September 1998.
[RFC2463] A. Conta and S. Deering. Internet Control Message Protocol [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
RFC 2463, December 1998. RFC 2463, December 1998.
[RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over
Satellite Channels using Standard Mechanisms. RFC 2488. January Satellite Channels using Standard Mechanisms. RFC 2488. January
1999. 1999.
[RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina, [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina,
Generic Routing Encapsulation (GRE), RFC 2784, March 2000. Generic Routing Encapsulation (GRE), RFC 2784, March 2000.
 End of changes. 14 change blocks. 
42 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/