Quick-Start for TCP and IP

Document Type Expired Internet-Draft (individual in tsv area)
Authors Amit Jain  , Sally Floyd
Last updated 2015-10-14 (latest revision 2005-02-22)
Stream Internet Engineering Task Force (IETF)
Expired & archived
plain text ps pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state Expired (IESG: Dead)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Allison Mankin
IESG note For tsvwg agenda at IETF61
Send notices to pasi.sarolahti@iki.fi, jon.peterson@neustar.biz, mallman@icir.org

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


This draft specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and at times in the middle of a data transfer. While Quick-Start is designed to be used by a range of transport protocols, in this document we describe its use with TCP. By using Quick-Start, a TCP host, say, host A, would indicate its desired sending rate in bytes per second, using a Quick Start Request option in the IP header of a TCP packet. A Quick-Start request for a higher sending rate would be sent in a TCP packet. Each router along the path could, in turn, either approve the requested rate, reduce the requested rate, or indicate that the Quick-Start request is not approved. If the Quick-Start request is not approved, then the sender would use the default congestion control mechanisms. The Quick-Start mechanism can determine if there are routers along the path that do not understand the Quick- Start Request option, or have not agreed to the Quick-Start rate request. TCP host B communicates the final rate request to TCP host A in a transport-level Quick-Start Response in an answering TCP packet. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and all of the routers along the path support the Quick-Start Request.


Amit Jain (ajain@netscaler.com)
Sally Floyd (floyd@icir.org)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)