Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4782

Quick-Start for TCP and IP

Pages: 82
Experimental
Errata
Part 4 of 4 – Pages 59 to 82
First   Prev   None

Top   ToC   RFC4782 - Page 59   prevText

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.)
Top   ToC   RFC4782 - Page 60
   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
Top   ToC   RFC4782 - Page 61
   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.
Top   ToC   RFC4782 - Page 62
   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.
Top   ToC   RFC4782 - Page 63

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.
Top   ToC   RFC4782 - Page 64
   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
Top   ToC   RFC4782 - Page 65
   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.
Top   ToC   RFC4782 - Page 66
   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
Top   ToC   RFC4782 - Page 67
   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
Top   ToC   RFC4782 - Page 68
   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
Top   ToC   RFC4782 - Page 69
   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
Top   ToC   RFC4782 - Page 70
   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:
Top   ToC   RFC4782 - Page 71
   (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.
Top   ToC   RFC4782 - Page 72
   (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
Top   ToC   RFC4782 - Page 73
   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.
Top   ToC   RFC4782 - Page 74

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.
Top   ToC   RFC4782 - Page 75
   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.
Top   ToC   RFC4782 - Page 76
   [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.
Top   ToC   RFC4782 - Page 77
   [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.
Top   ToC   RFC4782 - Page 78
   [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.
Top   ToC   RFC4782 - Page 79
   [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.
Top   ToC   RFC4782 - Page 80
   [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.
Top   ToC   RFC4782 - Page 81

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
Top   ToC   RFC4782 - Page 82
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.