Appendix B. Design Decisions
B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
This document has proposed using an IP Option for the Quick-Start
Request from the sender to the receiver, and using transport
mechanisms for the Quick-Start Response from the receiver back to the
sender. In this section, we discuss alternate mechanisms, and
consider whether ICMP ([RFC792], [RFC4443]) or RSVP [RFC2205]
protocols could be used for delivering the Quick-Start Request.
Being a control protocol used between Internet nodes, one could argue
that ICMP is the ideal method for requesting permission for faster
start-up from routers. The ICMP header is above the IP header.
Quick-Start could be accomplished with ICMP as follows: If 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 the ICMP
Quick-Start Request. The ICMP Quick-Start Request would have to pass
by the routers on the path to the receiver, possibly using the IP
Router Alert option [RFC2113]. A router that approves the Quick-
Start Request would take the same actions as in the case with the
Quick-Start IP Option, and forward the packet to the next router
along the path. A router that does not approve the Quick-Start
Request, even with a decreased value for the Requested Rate, would
delete the ICMP Quick-Start Request, and send an ICMP Reply to the
sender that the request was not approved. If the ICMP Reply was
dropped in the network, and did not reach the receiver, the sender
would still know that the request was not approved from the absence
of feedback from the receiver. If the ICMP Quick-Start Request was
dropped in the network due to congestion, the sender would assume
that the request was not approved. The ICMP message would need the
source and destination port numbers for demultiplexing at the end
nodes. If the ICMP Quick-Start Request reached the receiver, the
receiver would use transport-level or application-level mechanisms to
send a response to the sender, exactly as with the IP Option.
One benefit of using ICMP would be that the delivery of the TCP SYN
packet or other initial packet would not be delayed by IP option
processing at routers. A greater advantage is that if middleboxes
were blocking packets with Quick-Start Requests, using the Quick-
Start Request in a separate ICMP packet would mean that the middlebox
behavior would not affect the connection as a whole. (To get this
robustness to middleboxes with TCP using an IP Quick-Start Option,
one would have to have a TCP-level Quick-Start Request packet that
could be sent concurrently with, but separately from, the TCP SYN
However, there are a number of disadvantages to using ICMP. Some
firewalls and middleboxes may not forward the ICMP Quick-Start
Request packets. (If an ICMP Reply packet from a router to the
sender is dropped in the network, the sender would still know that
the request was not approved, as stated earlier, so this would not be
as serious of a problem.) In addition, it would be difficult, if not
impossible, for a router in the middle of an IP tunnel to deliver an
ICMP Reply packet to the actual source, for example, when the inner
IP header is encrypted, as in IPsec ESP tunnel mode [RFC4301].
Again, however, the ICMP Reply packet would not be essential to the
correct operation of ICMP Quick-Start.
Unauthenticated out-of-band ICMP messages could enable some types of
attacks by third-party malicious hosts that are not possible when the
control information is carried in-band with the IP packets that can
only be altered by the routers on the connection path. Finally, as a
minor concern, using ICMP would cause a small amount of additional
traffic in the network, which is not the case when using IP options.
With some modifications, RSVP [RFC2205] could be used as a bearer
protocol for carrying the Quick-Start Requests. Because routers are
expected to process RSVP packets more extensively than the normal
transport protocol IP packets, delivering a Quick-Start rate request
using an RSVP packet would seem an appealing choice. However, Quick-
Start with RSVP would require a few differences from the conventional
usage of RSVP. Quick-Start would not require periodical refreshing
of soft state, because Quick-Start does not require per-connection
state in routers. Quick-Start Requests would be transmitted
downstream from the sender to receiver in the RSVP Path messages,
which is different from the conventional RSVP model where the
reservations originate from the receiver. Furthermore, the Quick-
Start Response would be sent using the transport-level or
application-level mechanisms, instead of using the RSVP Resv message.
If RSVP was used for carrying a Quick-Start Request, a new "Quick-
Start Request" class object would be included in the RSVP Path
message that is sent from the sender to receiver. The object would
contain the rate request field in addition to the common length and
type fields. The Send_TTL field in the RSVP common header could be
used as the equivalent of the QS TTL field. The Quick-Start capable
routers along the path would inspect the Quick-Start Request object
in the RSVP Path message, decrement Send_TTL, and adjust the rate
request field if needed. If an RSVP router did not understand the
Quick-Start Request object, it would reject the entire RSVP message
and send an RSVP PathErr message back to the sender. When an RSVP
message with the Quick-Start Request object reaches the receiver, the
receiver sends a Quick-Start Reply message in the corresponding
transport protocol header in the same way as described in the context
of IP options earlier. If the RSVP message with the Quick-Start
Request object was dropped along the path, the transport sender would
simply proceed with the normal congestion control procedures.
Much of the discussion about benefits and drawbacks of using ICMP for
making the Quick-Start Request also applies to the RSVP case. If the
Quick-Start Request was transmitted in a separate packet instead of
as an IP option, the transport protocol packet delivery would not be
delayed due to IP option processing at the routers, and the initial
transport packets would reach their destination more reliably. The
possible disadvantages of using ICMP and RSVP are also expected to be
similar: middleboxes in the network may not be able to forward the
Quick-Start Request messages, and the IP tunnels might cause problems
for processing the Quick-Start Requests.
B.2. Alternate Encoding Functions
In this section, we look at alternate encoding functions for the Rate
Request field in the Quick-Start Request. The main requirements for
this function is that it should have a sufficiently wide range for
the requested rate. There is no need for overly fine-grained
precision in the requested rate. Similarly, while it would be
attractive for the encoding function to be easily computable, it is
also possible for end-nodes and routers to simply store the table
giving the mapping between the value N in the Rate Request field, and
the actual rate request f(N). In this section, we consider possible
encoding methods for Rate Request fields of different sizes,
including four-bit, eight-bit, and larger Rate Request fields.
One possible proposal would be for the Rate Request field to be
formatted in bits per second, scaled so that one unit equals M Kbps,
for some fixed value of M. Thus, for the value N in the Rate Request
field, the requested rate would be M*N Kbps.
Powers of two:
If a granularity of factors of two is sufficient for the Rate
Request, then the encoding function with the most range would be for
the requested rate to be K*2^N; for N, the value in the Rate Request
field; and for K, some constant. For N=0, the rate request would be
set to zero, regardless of the encoding function. For example, for
K=40,000 and an eight-bit Rate Request field, the request range would
be from 80 Kbps to 40*2^255 Kbps. This clearly would be an
unnecessarily large request range.
For a four-bit Rate Request field, the upper limit on the rate
request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps
would be fine for the Quick-Start rate request, and that connections
wishing to start up with a higher initial sending rate should be
encouraged to use other mechanisms, such as the explicit reservation
of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, then
five or six bits could be used for the Rate Request field.
The lower limit of 80 Kbps could be useful for flows with round-trip
times of a second or more. For a flow with a round-trip time of one
second, as is typical in some wireless networks, the TCP initial
window of 4380 bytes allowed by [RFC3390] (given appropriate packet
sizes) would translate to an initial sending rate of 35 Kbps. Thus,
for TCP flows, a rate request of 80 Kbps could be useful for some
flows with large round-trip times.
The lower limit of 80 Kbps could also be useful for some non-TCP
flows that send small packets, with at most one small packet every 10
ms. A rate request of 80 Kbps would translate to a rate of a hundred
100-byte packets per second (including packet headers). While some
small-packet flows with large round-trip times might find a smaller
rate request of 40 Kbps to be useful, our assumption is that a lower
limit of 80 Kbps on the rate request will be generally sufficient.
Again, if the lower limit of 80 kbps was not acceptable, then extra
bits could be used for the Rate Request field.
If the granularity of factors of two was too coarse, then the
encoding function could use a base less than two. An alternate form
for the encoding function would be to use a hybrid of linear and
A mantissa and exponent representation:
Section 4.4 of [B05] suggests a mantissa and exponent representation
for the Quick-Start encoding function. With e and f as the binary
numbers in the exponent and mantissa fields, and with 0 <= f < 1,
this would represent the rate (1+f)*2^e. [B05] suggests a mantissa
field for f of 8, 16, or 24 bits, with an exponent field for e of 8
bits. This representation would allow larger rate requests, with an
encoding that is less coarse than the powers-of-two encoding used in
Constraints of the transport protocol:
We note that the Rate Request is also constrained by the abilities of
the transport protocol. For example, for TCP with Window Scaling,
the maximum window is at most 2**30 bytes. For a TCP connection with
a long, 1 second round-trip time, this would give a maximum sending
rate of 1.07 Gbps.
B.3. The Quick-Start Request: Packets or Bytes?
One of the design questions is whether the Rate Request field should
be in bytes per second or in packets per second. We discuss this
separately from the perspective of the transport, and from the
perspective of the router.
For TCP, the results from the Quick-Start Request are translated into
a congestion window in bytes, using the measured round-trip time and
the MSS. This window applies only to the bytes of data payload, and
does not include the bytes in the TCP or IP packet headers. Other
transport protocols would conceivably use the Quick-Start Request
directly in packets per second, or could translate the Quick-Start
Request to a congestion window in packets.
The assumption of this document is that the router only approves the
Quick-Start Request when the output link is significantly
underutilized. For this, the router could measure the available
bandwidth in bytes per second, or could convert between packets and
bytes by some mechanism.
If the Quick-Start Request was in bytes per second, and applied only
to the data payload, then the router would have to convert from bytes
per second of data payload, to bytes per second of packets on the
wire. If the Rate Request field was in bytes per second, and the
sender ended up using very small packets, this could translate to a
significantly larger number in terms of bytes per second on the wire.
Therefore, for a Quick-Start Request in bytes per second, it makes
most sense for this to include the transport and IP headers as well
as the data payload. Of course, this will be, at best, a rough
approximation on the part of the sender; the transport-level sender
might not know the size of the transport and IP headers in bytes, and
might know nothing at all about the separate headers added in IP
tunnels downstream. This rough estimate seems sufficient, however,
given the overall lack of fine precision in Quick-Start
It has been suggested that the router could possibly use information
from the MSS option in the TCP packet header of the SYN packet to
convert the Quick-Start Request from packets per second to bytes per
second, or vice versa. This would be problematic for several
reasons. First, if IPsec is used, the TCP header will be encrypted.
Second, the MSS option is defined as the maximum MSS that the TCP
sender expects to receive, not the maximum MSS that the TCP sender
plans to send [RFC793]. However, it is probably often the case that
this MSS also applies as an upper bound on the MSS used by the TCP
sender in sending.
We note that the sender does not necessarily know the Path MTU when
the Quick-Start Request is sent, or when the initial window of data
is sent. Thus, with IPv4, packets from the initial window could end
up being fragmented in the network if the "Don't Fragment" (DF) bit
is not set [RFC1191]. A Rate Request in bytes per second is
reasonably robust to fragmentation. Clearly, a Rate Request in
packets per second is less robust in the presence of fragmentation.
Interactions between larger initial windows and Path MTU Discovery
are discussed in more detail in RFC 3390 [RFC3390].
For a Quick-Start Request in bytes per second, the transport senders
would have the additional complication of estimating the bandwidth
usage added by the packet headers.
We have chosen a Rate Request field in bytes per second rather than
in packets per second because it seems somewhat more robust,
particularly to routers.
B.4. Quick-Start Semantics: Total Rate or Additional Rate?
For a Quick-Start Request sent in the middle of a connection, there
are two possible semantics for the Rate Request field, as follows:
(1) Total Rate: The requested Rate Request is the requested total
rate for the connection, including the current rate; or
(2) Additional Rate: The requested Rate Request is the requested
increase in the total rate for that connection, over and above
the current sending rate.
When the Quick-Start Request is sent after an idle period, the
current sending rate is zero, and there is no difference between (1)
and (2) above. However, a Quick-Start Request can also be sent in
the middle of a connection that has not been idle, e.g., after a
mobility event, or after an application-limited period when the
sender is suddenly ready to send at a much higher rate. In this
case, there can be a significant difference between (1) and (2)
above. In this section, we consider briefly the tradeoffs between
these two options, and explain why we have chosen the `Total Rate'
The Total Rate semantics makes it easier for routers to "allocate"
the same rate to all connections. This lends itself to fairness, and
improves convergence times between old and new connections. With the
Additional Rate semantics, the router would not necessarily know the
current sending rates of the flows requesting additional rates, and
therefore would not have sufficient information to use fairness as a
metric in granting rate requests. With the Total Rate semantics, the
fairness is automatic; the router is not granting rate requests for
*additional* bandwidth without knowing the current sending rates of
the different flows.
The Additional Rate semantics also lends itself to gaming by the
connection, with senders sending frequent Quick-Start Requests in the
hope of gaining a higher rate. If the router is granting the same
maximum rate for all rate requests, then there is little benefit to a
connection of sending a rate request over and over again. However,
if the router is granting an *additional* rate with each rate
request, over and above the current sending rate, then it is in a
connection's interest to send as many rate requests as possible, even
if very few of them are, in fact, granted.
Appendix E discusses a Report of Current Sending Rate as one possible
function in the Quick-Start Option. However, we have not
standardized this possible use at this time.
B.5. Alternate Responses to the Loss of a Quick-Start Packet
Section 4.6 discusses TCP's response to the loss of a Quick-Start
packet in the initial window. This section discusses several
One possible alternative to reverting to the default Slow-Start after
the loss of a Quick-Start packet from the initial window would have
been to halve the congestion window and continue in congestion
avoidance. However, we note that this would not have been a
desirable response for either the connection or for the network as a
whole. The packet loss in the initial window indicates that Quick-
Start failed in finding an appropriate congestion window, meaning
that the congestion window after halving may easily also be wrong.
A more moderate alternate would be to continue in congestion
avoidance from a window of (W-D)/2, where W is the Quick-Start
congestion window, and D is the number of packets dropped or marked
from that window. However, such an approach would implicitly assume
that the number of Quick-Start packets delivered is a good indication
of the appropriate available bandwidth for that flow, even though
other packets from that window were dropped in the network. And,
further, that using half the number of segments that were
successfully transmitted is conservative enough to account for the
possibly inaccurate congestion window indication. We believe that
such an assumption would require more analysis at this point,
particularly in a network with a range of packet dropping mechanisms
at the router, and we cannot recommend it at this time.
Another drawback of approaches that don't revert back to slow-start
when a Quick-Start packet in the initial window is dropped is that
such approaches could give the TCP receiver a greater incentive to
lie about the Quick-Start Request. If the sender reverts to slow-
start when a Quick-Start packet in the initial window is dropped,
this diminishes the benefit a receiver would get from a Quick-Start
request that resulted in a dropped or ECN-marked packet.
B.6. Why Not Include More Functionality?
This proposal for Quick-Start is a rather coarse-grained mechanism
that would allow a connection to use a higher sending rate along
underutilized paths, but that does not attempt to provide a next-
generation transport protocol or congestion control mechanism, and
does not attempt the goal of providing very high throughput with very
low delay. Appendix A.4 discusses a number of proposals (such as
XCP, MaxNet, and AntiECN) that provide more fine-grained per-packet
feedback from routers than the current congestion control mechanisms
and that attempt these more ambitious goals.
Compared to proposals such as XCP and AntiECN, Quick-Start offers
much less control. Quick-Start does not attempt to provide a new
congestion control mechanism, but simply to get permission from
routers for a higher sending rate at start-up, or after an idle
period. Quick-Start can be thought of as an "anti-congestion-
control" mechanism that is only of any use when all the routers along
the path are significantly underutilized. Thus, Quick-Start is of no
use towards a target of high link utilization, or fairness in a
high-utilization scenario, or controlling queueing delay during high
utilization, or anything of the like.
At the same time, Quick-Start would allow larger initial windows than
would proposals such as AntiECN, requires less input to routers than
XCP (e.g., XCP's cwnd and RTT fields), and would require less
frequent feedback from routers than any new congestion control
mechanism. Thus, Quick-Start is significantly less powerful than
proposals for new congestion control mechanisms, such as XCP and
AntiECN, but as powerful or more powerful in terms of the specific
issue of allowing larger initial windows. Also, (we think) it is
more amenable to incremental deployment in the current Internet.
We do not discuss proposals such as XCP in detail, but simply note
that there are a number of open questions. One question concerns
whether there is a pressing need for more sophisticated congestion
control mechanisms, such as XCP, in the Internet. Quick-Start is
inherently a rather crude tool that does not deliver assurances about
maintaining high link utilization and low queueing delay; Quick-Start
is designed for use in environments that are significantly
underutilized, and addresses the single question of whether a higher
sending rate is allowed. New congestion control mechanisms with more
fine-grained feedback from routers could allow faster start-ups even
in environments with rather high link utilization. Is this a
pressing requirement? Are the other benefits of more fine-grained
congestion control feedback from routers a pressing requirement?
We would argue that even if more fine-grained per-packet feedback
from routers was implemented, it is reasonable to have a separate
mechanism, such as Quick-Start, for indicating an allowed initial
sending rate, or an allowed total sending rate after an idle or
One difference between Quick-Start and current proposals for fine-
grained per-packet feedback, such as XCP, is that XCP is designed to
give robust performance even in the case where different packets
within a connection routinely follow different paths. XCP achieves
relatively robust performance in the presence of multipath routing by
using per-packet feedback, where the feedback carried in a single
packet is about the relative increase or decrease in the rate or
window to take effect when that particular packet is acknowledged,
not about the allowed sending rate for the connection as a whole.
In contrast, Quick-Start sends a single Quick-Start Request, and the
answer to that request gives the allowed sending rate for an entire
window of data. As a result, Quick-Start could be problematic in an
environment where some fraction of the packets in a window of data
take path A, and the rest of the packets take path B; for example,
the Quick-Start Request could have traveled on path A, while half the
Quick-Start packets sent in the succeeding round-trip time are routed
on path B. We note that [ZDPS01] shows Internet paths to be stable
on the order of RTTs.
There are also differences between Quick-Start and some of the
proposals for per-packet feedback in terms of the number of bits of
feedback required from the routers to the end-nodes. Quick-Start
uses four bits of feedback in the rate request field to indicate the
allowed sending rate. XCP allocates a byte for per-packet feedback,
though there has been discussion of variants of XCP with less per-
packet feedback. This would be more like other proposals, such as
anti-ECN, that use a single bit of feedback from routers to indicate
that the sender can increase as fast as slow-starting, in response to
this particular packet acknowledgement. In general, there is
probably considerable power in fine-grained proposals with only two
bits of feedback, indicating that the sender should decrease,
maintain, or increase the sending rate or window when this packet is
acknowledged. However, the power of Quick-Start would be
considerably limited if it was restricted to only two bits of
feedback; it seems likely that determining the initial sending rate
fundamentally requires more bits of feedback from routers than does
the steady-state, per-packet feedback to increase or decrease the
On a more practical level, one difference between Quick-Start and
proposals for per-packet feedback is that there are fewer open issues
with Quick-Start than there would be with a new congestion control
mechanism. Because Quick-Start is a mechanism for requesting an
initial sending rate in an underutilized environment, its fairness
issues are less severe than those of a general congestion control
mechanism. With Quick-Start, there is no need for the end nodes to
tell the routers the round-trip time and congestion window, as is
done in XCP; all that is needed is for the end nodes to report the
requested sending rate.
Table 3 provides a summary of the differences between Quick-Start and
proposals for per-packet congestion control feedback.
Quick-Start Per-Packet Feedback
Semantics: | Allowed sending rate | Change in rate/window,
| per connection. | per-packet.
Relationship to | In addition. | Replacement.
congestion ctrl: | |
Frequency: | Start-up, or after | Every packet.
| an idle period. |
Limitations: | Only useful on | General congestion
| underutilized paths.| control mechanism.
Input to routers: | Rate request. |RTT, cwnd, request (XCP)
| | None (Anti-ECN).
Bits of feedback: | Four bits for | A few bits would
| rate request. | suffice?
Table 3: Differences between Quick-Start and Proposals for
Fine-Grained Per-Packet Feedback.
A separate question concerns whether mechanisms, such as Quick-Start,
in combination with HighSpeed TCP and other changes in progress,
would make a significant contribution towards meeting some of these
needs for new congestion control mechanisms. This could be viewed as
a positive step towards meeting some of the more pressing current
needs with a simple and reasonably deployable mechanism, or
alternately, as a negative step of unnecessarily delaying more
fundamental changes. Without answering this question, we would note
that our own approach tends to favor the incremental deployment of
relatively simple mechanisms, as long as the simple mechanisms are
not short-term hacks, but mechanisms that lead the overall
architecture in the fundamentally correct direction.
B.7. Alternate Implementations for a Quick-Start Nonce
B.7.1. An Alternate Proposal for the Quick-Start Nonce
An alternate proposal for the Quick-Start Nonce from [B05] would be
for an n-bit field for the QS Nonce, with the sender generating a
random nonce when it generates a Quick-Start Request. Each router
that reduces the Rate Request by r would hash the QS nonce r times,
using a one-way hash function such as MD5 [RFC1321] or the secure
hash 1 [SHA1]. The receiver returns the QS nonce to the sender.
Because the sender knows the original value for the nonce, and the
original rate request, the sender knows the total number of steps s
that the rate has been reduced. The sender then hashes the original
nonce s times to check whether the result is the same as the nonce
returned by the receiver.
This alternate proposal for the nonce would be considerably more
powerful than the QS nonce described in Section 3.4, but it would
also require more CPU cycles from the routers when they reduce a
Quick-Start Request, and from the sender in verifying the nonce
returned by the receiver. As reported in [B05], routers could
protect themselves from processor exhaustion attacks by limiting the
rate at which they will approve reductions of Quick-Start Requests.
Both the Function field and the Reserved field in the Quick-Start
Option would allow the extension of Quick-Start to use Quick-Start
requests with the alternate proposal for the Quick-Start Nonce, if it
was ever desired.
B.7.2. The Earlier Request-Approved Quick-Start Nonce
An earlier version of this document included a Request-Approved
Quick-Start Nonce (QS Nonce) that was initialized by the sender to a
non-zero, `random' eight-bit number, along with a QS TTL that was
initialized to the same value as the TTL in the IP header. The
Request-Approved Quick-Start Nonce would have been returned by the
transport receiver to the transport sender in the Quick-Start
Response. A router could deny the Quick-Start Request by failing to
decrement the QS TTL field, by zeroing the QS Nonce field, or by
deleting the Quick-Start Request from the packet header. The QS
Nonce was included to provide some protection against broken
downstream routers, or against misbehaving TCP receivers that might
be inclined to lie about whether the Rate Request was approved. This
protection is now provided by the QS Nonce, by the use of a random
initial value for the QS TTL field, and by Quick-Start-capable
routers hopefully either deleting the Quick-Start Option or zeroing
the QS TTL and QS Nonce fields when they deny a request.
With the old Request-Approved Quick-Start Nonce, along with the QS
TTL field set to the same value as the TTL field in the IP header,
the Quick-Start Request mechanism would have been self-terminating;
the Quick-Start Request would terminate at the first participating
router after a non-participating router had been encountered on the
path. This minimizes unnecessary overhead incurred by routers
because of option processing for the Quick-Start Request. In the
current specification, this "self-terminating" property is provided
by Quick-Start-capable routers hopefully either deleting the Quick-
Start Option or zeroing the Rate Request field when they deny a
request. Because the current specification uses a random initial
value for the QS TTL, Quick-Start-capable routers can't tell if the
Quick-Start Request is invalid because of non-Quick-Start-capable
routers upstream. This is the cost of using a design that makes it
difficult for the receiver to cheat about the value of the QS TTL.
Appendix C. Quick-Start with DCCP
DCCP is a new transport protocol for congestion-controlled,
unreliable datagrams, intended for applications such as streaming
media, Internet telephony, and online games. In DCCP, the
application has a choice of congestion control mechanisms, with the
currently-specified Congestion Control Identifiers (CCIDs) being CCID
2 for TCP-like congestion control, and CCID 3 for TCP Friendly Rate
Control (TFRC), an equation-based form of congestion control. We
refer the reader to [RFC4340] for a more detailed description of DCCP
and congestion control mechanisms.
Because CCID 3 uses a rate-based congestion control mechanism, it
raises some new issues about the use of Quick-Start with transport
protocols. In this document, we don't attempt to specify the use of
Quick-Start with DCCP. However, we do discuss some of the issues
that might arise.
In considering the use of Quick-Start with CCID 3 for requesting a
higher initial sending rate, the following questions arise:
(1) How does the sender respond if a Quick-Start packet is dropped?
As in TCP, if an initial Quick-Start packet is dropped, the CCID
3 sender should revert to the congestion control mechanisms it
would have used if the Quick-Start Request had not been approved.
(2) When does the sender decide there has been no feedback from the
Unlike TCP, CCID 3 does not use acknowledgements for every
packet, or for every other packet. In contrast, the CCID 3
receiver sends feedback to the sender roughly once per round-trip
time. In CCID 3, the allowed sending rate is halved if no
feedback is received from the receiver in at least four round-
trip times (when the sender is sending at least one packet every
two round-trip times). When a Quick-Start Request is used, it
would seem necessary to use a smaller time interval, e.g., to
reduce the sending rate if no feedback arrives from the receiver
in at least two round-trip times.
The question also arises of how the sending rate should be reduced
after a period of no feedback from the receiver. As with TCP, the
default CCID 3 response of halving the sending rate is not
necessarily a sufficient response to the absence of feedback; an
alternative is to reduce the sending rate to the sending rate that
would have been used if no Quick-Start Request had been approved.
That is, if a CCID 3 sender uses a Quick-Start Request, special rules
might be required to handle the sender's response to a period of no
feedback from the receiver regarding the Quick-Start packets.
Similarly, in considering the use of Quick-Start with CCID 3 for
requesting a higher sending rate after an idle period, the following
(1) What rate does the sender request?
As in TCP, there is a straightforward answer to the rate request
that the CCID 3 sender should use in requesting a higher sending
rate after an idle period. The sender knows the current loss
event rate, either from its own calculations or from feedback
from the receiver, and can determine the sending rate allowed by
that loss event rate. This is the upper bound on the sending
rate that should be requested by the CCID 3 sender. A Quick-
Start Request is useful with CCID 3 when the sender is coming out
of an idle or underutilized period, because in standard
operation, CCID 3 does not allow the sender to send more than
twice as fast as the receiver has reported received in the most
recent feedback message.
(2) What is the response to loss?
The response to the loss of Quick-Start packets should be to
return to the sending rate that would have been used if Quick-
Start had not been requested.
(3) When does the sender decide there has been no feedback from the
As in the case of the initial sending rate, it would seem prudent
to reduce the sending rate if no feedback is received from the
receiver in at least two round-trip times. It seems likely that,
in this case, the sending rate should be reduced to the sending
rate that would have been used if no Quick-Start Request had been
Appendix D. Possible Router Algorithm
This specification does not tightly define the algorithm a router
uses when deciding whether to approve a Quick-Start Rate Request or
whether and how to reduce a Rate Request. A range of algorithms is
likely useful in this space and we consider the algorithm a
particular router uses to be a local policy decision. In addition,
we believe that additional experimentation with router algorithms is
necessary to have a solid understanding of the dynamics various
algorithms impose. However, we provide one particular algorithm in
this appendix as an example and as a framework for thinking about
[SAF06] provides several algorithms routers can use to consider
incoming Rate Requests. The decision process involves two
algorithms. First, the router needs to track the link utilization
over the recent past. Second, this utilization needs to be updated
by the potential new bandwidth from recent Quick-Start approvals, and
then compared with the router's notion of when it is underutilized
enough to approve Quick-Start Requests (of some size).
First, we define the "peak utilization" estimation technique (from
[SAF06]). This mechanism records the utilization of the link every S
seconds and stores the most recent N of these measurements. The
utilization is then taken as the highest utilization of the N
samples. This method, therefore, keeps N*S seconds of history. This
algorithm reacts rapidly to increases in the link utilization. In
[SAF06], S is set to 0.15 seconds, and experiments use values for N
ranging from 3 to 20.
Second, we define the "target" algorithm for processing incoming
Quick-Start Rate Requests (also from [SAF06]). The algorithm relies
on knowing the bandwidth of the outgoing link (which, in many cases,
can be easily configured), the utilization of the outgoing link (from
an estimation technique such as given above), and an estimate of the
potential bandwidth from recent Quick-Start approvals.
Tracking the potential bandwidth from recent Quick-Start approvals is
another case where local policy dictates how it should be done. The
simplest method, outlined in Section 8.2, is for the router to keep
track of the aggregate Quick-Start rate requests approved in the most
recent two or more time intervals, including the current time
interval, and to use the sum of the aggregate rate requests over
these time intervals as the estimate of the approved Rate Requests.
The experiments in [SAF06] keep track of the aggregate approved Rate
Requests over the most recent two time intervals, for intervals of
The target algorithm also depends on a threshold (qs_thresh) that is
the fraction of the outgoing link bandwidth that represents the
router's notion of "significantly underutilized". If the
utilization, augmented by the potential bandwidth from recent Quick-
Start approvals, is above this threshold, then no Quick-Start Rate
Requests will be approved. If the utilization, again augmented by
the potential bandwidth from recent Quick-Start approvals, is less
than the threshold, then Rate Requests can be approved. The Rate
Requests will be reduced such that the bandwidth allocated would not
drive the utilization to more than the given threshold. The
util_bw = bandwidth * utilization;
util_bw = util_bw + recent_qs_approvals;
if (util_bw < (qs_thresh * bandwidth))
approved = (qs_thresh * bandwidth) - util_bw;
if (rate_request < approved)
approved = rate_request;
approved = round_down (approved);
recent_qs_approvals += approved;
Also note that, given that Rate Requests are fairly coarse, the
approved rate should be rounded down when it does not fall exactly on
one of the rates allowed by the encoding scheme.
Routers that wish to keep close track of the allocated Quick-Start
bandwidth could use Approved Rate reports to learn when rate requests
had been decremented downstream in the network, and also to learn
when a sender begins to use the approved Quick-Start Request.
Appendix E. Possible Additional Uses for the Quick-Start Option
The Quick-Start Option contains a four-bit Function field in the
third byte, enabling additional uses to be defined for the Quick-
Start Option. In this section, we discuss some of the possible
additional uses that have been discussed for Quick-Start. The
Function field makes it easy to add new functions for the Quick-
Report of Current Sending Rate: A Quick-Start Request with the
`Report of Current Sending Rate' codepoint set in the Function field
would be using the Rate Request field to report the current estimated
sending rate for that connection. This could accompany a second
Quick-Start Request in the same packet containing a standard rate
request, for a connection that is using Quick-Start to increase its
current sending rate.
Request to Increase Sending Rate: A codepoint for `Request to
Increase Sending Rate' in the Function field would indicate that the
connection is not idle or just starting up, but is attempting to use
Quick-Start to increase its current sending rate. This codepoint
would not change the semantics of the Rate Request field.
RTT Estimate: If a codepoint for `RTT Estimate' was used, a field for
the RTT Estimate would contain one or more bits giving the sender's
rough estimate of the round-trip time, if known. E.g., the sender
could estimate whether the RTT was greater or less than 200 ms.
Alternately, if the sender had an estimate of the RTT when it sends
the Rate Request, the two-bit Reserved field at the end of the
Quick-Start Option could be used for a coarse-grained encoding of the
Informational Request: An Informational Request codepoint in the
Function field would indicate that a request is purely informational,
for the sender to find out if a rate request would be approved, and
what size rate request would be approved when the Informational
Request is sent. For example, an Informational Request could be
followed one round-trip time later by a standard Quick-Start Request.
A router approving an Informational Request would not consider this
as an approval for Quick-Start bandwidth to be used, and would not be
under any obligation to approve a similar standard Quick-Start
Request one round-trip time later. An Informational Request with a
rate request of zero could be used by the sender to find out if all
of the routers along the path supported Quick-Start.
Use Format X for the Rate Request Field: A Quick-Start codepoint for
`Use Format X for the Rate Request Field' would indicate that an
alternate format was being used for the Rate Request field.
Do Not Decrement: A Do Not Decrement codepoint could be used for a
Quick-Start Request where the sender would rather have the request
denied than to have the rate request decremented in the network.
This could be used if the sender was only interested in using Quick-
Start if the original rate request was approved.
Temporary Bandwidth Use: A Temporary codepoint has been proposed to
indicate that a connection would only use the requested bandwidth for
a single time interval.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
Congestion Windows", RFC 3742, March 2004.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased
Initial TCP Window Size", RFC 2415, September 1998.
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", BCP 28, RFC
2488, January 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
and B. Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC
2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
L., and V. Paxson, "Stream Control Transmission Protocol",
RFC 2960, October 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
BCP 60, RFC 3360, August 2002.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, December 2003.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", RFC
3662, December 2003.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig,
R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood,
"Advice for Internet Subnetwork Designers", BCP 89, RFC
3819, July 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, March 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Version
6 (IPv6) Specification", RFC 4443, March 2006.
[AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP
with Larger Initial Windows. ACM Computer Communication
Review, July 1998.
[B05] Briscoe, B., "Review: Quick-Start for TCP and IP",
[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols
of the new GSM Phase 2+ General Packet Radio Service. IEEE
Communications Magazine, pages 94--104, August 1997.
[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-
Layer Protocol Tracing in a GPRS Network. In Proceedings of
the IEEE Vehicular Technology Conference (Fall VTC2002),
Vancouver, Canada, September 2002.
[H05] P. Hoffman, email, October 2005. Citation for
acknowledgement purposes only.
[HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion
Detection: Evasion, Traffic Normalization, and End-to-End
Protocol Semantics, Proc. USENIX Security Symposium 2001.
[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM.
[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available
Bandwidth: Measurement Methodology, Dynamics, and Relation
with TCP Throughput, SIGCOMM 2002.
[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High
Bandwidth Delay Connections", Proceedings, IEEE ICC '03,
May 2003. <http://www.seas.upenn.edu/~kunniyur/>.
[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G.
Sterbenz. Explicit Transport Error Notification (ETEN) for
Error-Prone Wireless and Satellite Networks. Technical
Report No. 8333, BBN Technologies, March 2002.
[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet
Congestion Control for Future High Bandwidth-Delay Product
Environments. ACM Sigcomm 2002, August 2002.
[KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed
Algorithm for Low Priority Data Transfer. INFOCOM 2003,
[KSEPA04] Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig
Partridge, Mark Allman. Explicit Transport Error
Notification (ETEN) for Error-Prone Wireless and Satellite
Networks. Computer Networks, 46(3), October 2004.
[L05] Guohan Lu, Nonce in TCP Quick Start, September 2005.
[MH06] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", Work in Progress, December 2006.
[MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring
Interactions Between Transport Protocols and Middleboxes,
Internet Measurement Conference 2004, August 2004.
[MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring
the Evolution of Transport Protocols in the Internet.
Computer Communications Review, April 2005.
[MaxNet] MaxNet Home Page,
[P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection,
report to John Heidemann, 2000, private communication.
Citation for acknowledgement purposes only.
[PABL+05] Ruoming Pang, Mark Allman, Mike Bennett, Jason Lee, Vern
Paxson, Brian Tierney. A First Look at Modern Enterprise
Traffic. ACM SIGCOMM/USENIX Internet Measurement
Conference, October 2005.
[PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh
Krishnan, James P.G. Sterbenz. A Swifter Start for TCP.
Technical Report No. 8339, BBN Technologies, March 2002.
[RW03] Mattia Rossi and Michael Welzl, On the Impact of IP Option
Processing, Preprint-Reihe des Fachbereichs Mathematik -
Informatik, No. 15, Institute of Computer Science,
University of Innsbruck, Austria, October 2003.
[RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option
Processing - Part 2, Preprint-Reihe des Fachbereichs
Mathematik - Informatik, No. 26, Institute of Computer
Science, University of Innsbruck, Austria, July 2004.
[S02] Ion Stoica, private communication, 2002. Citation for
acknowledgement purposes only.
[SAF06] Pasi Sarolahti, Mark Allman, and Sally Floyd. Determining
an Appropriate Sending Rate Over an Underutilized Network
Path. February 2006.
[SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare
network bandwidth to improve TCP performance", ACM SIGCOMM
2005 Work in Progress session, August 2005,
[SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce,
Washington, D.C., publication 180-1, April 1995.
[SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP
Quick Start with NS-2. Class Project, December 2002. Not
publicly available; citation for acknowledgement purposes
[V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A
Mechanism for Background Transfers. OSDI 2002.
[VH97] V. Visweswaraiah and J. Heidemann, Improving Restart of
Idle TCP Connections, Technical Report 97-661, University
of Southern California, November 1997.
[W00] Michael Welzl: PTP: Better Feedback for Adaptive
Distributed Multimedia Applications on the Internet, IPCCC
2000 (19th IEEE International Performance, Computing, And
Communications Conference), Phoenix, Arizona, USA, 20-22
[ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the
Constancy of Internet Path Properties, Proc. ACM SIGCOMM
Internet Measurement Workshop, November 2001.
[ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data
Transfers: Theory, Architectural Support, and Simulation
Results, NOSSDAV 2000, June 2000.
Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research)
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: (440) 235-1792
Nokia Research Center
P.O. Box 407
FI-00045 NOKIA GROUP
Phone: +358 50 4876607
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
Funding for the RFC Editor function is currently provided by the