
Cite this RFC:TXT | XML | BibTeX
DOI: https://doi.org/10.17487/RFC4782
Discuss this RFC: Send questions or comments to the mailing listtsvwg@ietf.org
Other actions:View Errata | Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 4782
This document specifies an optional Quick-Start mechanism fortransport protocols, in cooperation with routers, to determine anallowed sending rate at the start and, at times, in the middle of adata transfer (e.g., after an idle period). While Quick-Start isdesigned to be used by a range of transport protocols, in thisdocument we only specify its use with TCP. Quick-Start is designedto allow connections to use higher sending rates when there issignificant unused bandwidth along the path, and the sender and allof the routers along the path approve the Quick-Start Request.
This document describes many paths where Quick-Start Requests wouldnot be approved. These paths include all paths containing routers,IP tunnels, MPLS paths, and the like that do not support Quick-Start. These paths also include paths with routers or middleboxesthat drop packets containing IP options. Quick-Start Requests couldbe difficult to approve over paths that include multi-access layer-two networks. This document also describes environments where theQuick-Start process could fail with false positives, with the senderincorrectly assuming that the Quick-Start Request had been approvedby all of the routers along the path. As a result of theseconcerns, and as a result of the difficulties and seeming absence ofmotivation for routers, such as core routers to deploy Quick-Start,Quick-Start is being proposed as a mechanism that could be of use incontrolled environments, and not as a mechanism that would beintended or appropriate for ubiquitous deployment in the globalInternet. This memo defines an Experimental Protocol for the Internet community.
For the definition ofStatus,seeRFC 2026.
For the definition ofStream, seeRFC 8729.