RFC 4782
Quick-Start for TCP and IP
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.B.1.1. ICMP
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 packet.)
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.B.1.2. RSVP
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. Linear functions: 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 exponential functions. 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 this document. 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 functionality. 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' semantics. 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 alternate responses. 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 underutilized period. 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
sending rate.
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.
Proposals for
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
receiver?
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
questions arise:
(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
receiver?
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
approved.
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
additional mechanisms.
[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 150 msec. 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 algorithm is: 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- Start Option. 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 RTT. 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.Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [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, September 2001. [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.Informative References
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997. [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 2000. [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, August 2002.
[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 2005. [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", <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html>, November 2005. [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. <http://www.icir.org/mallman/papers/>. [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet Congestion Control for Future High Bandwidth-Delay Product Environments. ACM Sigcomm 2002, August 2002. <http://ana.lcs.mit.edu/dina/XCP/>. [KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 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. <http://www.net-glyph.org/~lgh/nonce-usage.pdf>. [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. <http://www.icir.org/tbit/". [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, <http://netlab.caltech.edu/~bartek/maxnet.htm>. [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. <http://www.icir.org/mallman/papers/>. [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. <http://www.icir.org/floyd/quickstart.html>. [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, <https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf>. [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 only. [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 February 2000. <http://www.welzl.at/research/publications/>. [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.
Authors' Addresses
Sally Floyd Phone: +1 (510) 666-2989 ICIR (ICSI Center for Internet Research) EMail: floyd@icir.org URL: http://www.icir.org/floyd/ Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: (440) 235-1792 EMail: mallman@icir.org URL: http://www.icir.org/mallman/ Amit Jain F5 Networks EMail: a.jain@f5.com Pasi Sarolahti Nokia Research Center P.O. Box 407 FI-00045 NOKIA GROUP Finland Phone: +358 50 4876607 EMail: pasi.sarolahti@iki.fi
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 PURPOSE. Intellectual Property 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.