tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4782


Quick-Start for TCP and IP

Part 4 of 4, p. 59 to 82
Prev RFC Part


prevText      Top      Up      ToC       Page 59 
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

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

   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      Up      ToC       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'

   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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

       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      Up      ToC       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

       As in the case of the initial sending rate, it would seem prudent
       to reduce the sending rate if no feedback is received from the
       receiver in at least two round-trip times.  It seems likely that,
       in this case, the sending rate should be reduced to the sending
       rate that would have been used if no Quick-Start Request had been

Appendix D.  Possible Router Algorithm

   This specification does not tightly define the algorithm a router
   uses when deciding whether to approve a Quick-Start Rate Request or
   whether and how to reduce a Rate Request.  A range of algorithms is
   likely useful in this space and we consider the algorithm a
   particular router uses to be a local policy decision.  In addition,
   we believe that additional experimentation with router algorithms is
   necessary to have a solid understanding of the dynamics various
   algorithms impose.  However, we provide one particular algorithm in
   this appendix as an example and as a framework for thinking about
   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      Up      ToC       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      Up      ToC       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

   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      Up      ToC       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      Up      ToC       Page 76 
   [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
             October 1996.

   [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February

   [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

   [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      Up      ToC       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

   [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      Up      ToC       Page 78 
   [B05]     Briscoe, B., "Review: Quick-Start for TCP and IP",
             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.  <>.

   [KAPS02]  Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G.
             Sterbenz. Explicit Transport Error Notification (ETEN) for
             Error-Prone Wireless and Satellite Networks. Technical
             Report No. 8333, BBN Technologies, March 2002.

   [KHR02]   Dina Katabi, Mark Handley, and Charles Rohrs, Internet
             Congestion Control for Future High Bandwidth-Delay Product
             Environments. ACM Sigcomm 2002, August 2002.

   [KK03]    A. Kuzmanovic and E. W. Knightly.  TCP-LP: A Distributed
             Algorithm for Low Priority Data Transfer.  INFOCOM 2003,
             April 2003.

Top      Up      ToC       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.

   [MH06]    Mathis, M. and J. Heffner, "Packetization Layer Path MTU
             Discovery", Work in Progress, December 2006.

   [MAF04]   Alberto Medina, Mark Allman, and Sally Floyd, Measuring
             Interactions Between Transport Protocols and Middleboxes,
             Internet Measurement Conference 2004, August 2004.

   [MAF05]   Alberto Medina, Mark Allman, and Sally Floyd.  Measuring
             the Evolution of Transport Protocols in the Internet.
             Computer Communications Review, April 2005.

   [MaxNet]  MaxNet Home Page,

   [P00]     Joon-Sang Park, Bandwidth Discovery of a TCP Connection,
             report to John Heidemann, 2000, private communication.
             Citation for acknowledgement purposes only.

   [PABL+05] Ruoming Pang, Mark Allman, Mike Bennett, Jason Lee, Vern
             Paxson, Brian Tierney.  A First Look at Modern Enterprise
             Traffic.  ACM SIGCOMM/USENIX Internet Measurement
             Conference, October 2005.

   [PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh
             Krishnan, James P.G. Sterbenz. A Swifter Start for TCP.
             Technical Report No. 8339, BBN Technologies, March 2002.

   [RW03]    Mattia Rossi and Michael Welzl, On the Impact of IP Option
             Processing, Preprint-Reihe des Fachbereichs Mathematik -
             Informatik, No. 15, Institute of Computer Science,
             University of Innsbruck, Austria, October 2003.

   [RW04]    Mattia Rossi and Michael Welzl, On the Impact of IP Option
             Processing -   Part 2, Preprint-Reihe des Fachbereichs
             Mathematik - Informatik, No. 26, Institute of Computer
             Science, University of Innsbruck, Austria, July 2004.

Top      Up      ToC       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.

   [SGF05]   Singh, M., Guha, S., and P. Francis, "Utilizing spare
             network bandwidth to improve TCP performance", ACM SIGCOMM
             2005 Work in Progress session, August 2005,

   [SHA1]    "Secure Hash Standard", FIPS, U.S. Department of Commerce,
             Washington, D.C., publication 180-1, April 1995.

   [SH02]    Srikanth Sundarrajan and John Heidemann.  Study of TCP
             Quick Start with NS-2.  Class Project, December 2002.  Not
             publicly available; citation for acknowledgement purposes

   [V02]     A. Venkataramani, R. Kokku, and M. Dahlin.  TCP Nice: A
             Mechanism for Background Transfers.  OSDI 2002.

   [VH97]    V. Visweswaraiah and J. Heidemann, Improving Restart of
             Idle TCP Connections, Technical Report 97-661, University
             of Southern California, November 1997.

   [W00]     Michael Welzl: PTP: Better Feedback for Adaptive
             Distributed Multimedia Applications on the Internet, IPCCC
             2000 (19th IEEE International Performance, Computing, And
             Communications Conference), Phoenix, Arizona, USA, 20-22
             February 2000.

   [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      Up      ToC       Page 81 
Authors' Addresses

   Sally Floyd
   Phone: +1 (510) 666-2989
   ICIR (ICSI Center for Internet Research)

   Mark Allman
   ICSI Center for Internet Research
   1947 Center Street, Suite 600
   Berkeley, CA 94704-1198
   Phone: (440) 235-1792

   Amit Jain
   F5 Networks

   Pasi Sarolahti
   Nokia Research Center
   P.O. Box 407
   Phone: +358 50 4876607

Top      Up      ToC       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

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

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is currently provided by the
   Internet Society.