Quick-Start for TCP and IP
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com> Subject: Document Action: 'Quick-Start for TCP and IP' to Experimental RFC The IESG has approved the following document: - 'Quick-Start for TCP and IP ' <draft-ietf-tsvwg-quickstart-08.txt> as an Experimental RFC This document is the product of the Transport Area Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-quickstart-08.txt
Technical Summary This document defines an optional means of accelerating normal slow start(ish) transfer rate procedures of a transport protocol into the (potentially many) Mbps flows have access to. The Quickstart sending rate is requested, and never mandatory. The fall back is to normal slow start(ish) ramp ups, requiring many RTTs, in bandwidth utilized. This document outlines how Quickstart is used in TCP, but the mechanism is not specific to any transport protocol - with a lot of discussion on how it affects UDP (VoIP) flows. This document limits flows that can use Quickstart to at least 80kbps or higher. There are pitfalls and problems to be explored with this mechanism (most thought of are discussed extensively), which is why this is Experimental, instead of Standards Track. Rough running code of this mechanism already exists in several places, with generally positive results, even for VoIP. Working Group Summary There is strong consensus in the WG to publish this document. It has been reviewed by several people in the WG last call. Comments raised have been addressed. Protocol Quality This document is making an experimental, optional extension to transport protocol initial transfer rates. TCP is highlighted in the document, though other transport protocols are able to use this mechanism. It is not making a new protocol. This document has been well reviewed in the WG and comments raised have been addressed promptly. James Polk (firstname.lastname@example.org) has acted as Document Shepherd. Lars Eggert (email@example.com) has reviewed this document for the IESG. Note to RFC Editor Add the following text as the first item in Section 9.2: The cost of having a Quick-Start request packet dropped: Measurement studies cited earlier [MAF04] suggest that on a wide range of paths in the Internet, TCP SYN packets containing unknown IP options will be dropped. Thus, for the sender one risk in using Quick-Start is that the packet carrying the Quick-Start Request could be dropped in the network. It is particularly costly to the sender when a TCP SYN packet is dropped, because in this case the sender should wait for an RTO of three seconds before re-sending the SYN packet, as specified in Section 4.7.2.