Skip to main content

Avoiding Interactions of Quick-Start TCP and Flow Control

Document Type Expired Internet-Draft (individual)
Expired & archived
Author Michael Scharf
Last updated 2007-07-05 (Latest revision 2007-02-27)
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


This document describes methods to avoid interactions between the flow control of the Transmission Control Protocol (TCP) and the Quick-Start TCP mechanism. Quick-Start is an optional TCP congestion control extension that allows hosts to determine an allowed sending rate from feedback of routers along the path. With Quick-Start, data transfers can start with a potentially large congestion window and avoid the time-consuming slow-start. In order to fully utilize the data rate determined by Quick-Start, the sending host must not be limited by the TCP flow control, i. e., the amount of free buffer space advertised by the receive window. There are two potential interactions between Quick-Start and the TCP flow control: First, receivers might not provide sufficiently large buffer space after connection setup, or they may implement buffer allocation strategies that implicitly assume the slow-start behavior on the sender side. This document therefore provides guidelines for buffer allocation in hosts supporting the Quick-Start extension. Second, the TCP receive window scaling mechanism interferes with Quick-Start when being used in the initial three-way handshake connection setup. This document describes a simple solution to overcome this problem.


Michael Scharf

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