Appendix B.  Design Decisions

B.1.  Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP

   This document has proposed using an IP Option for the Quick-Start
   Request from the sender to the receiver, and using transport
   mechanisms for the Quick-Start Response from the receiver back to the
   sender.  In this section, we discuss alternate mechanisms, and
   consider whether ICMP ([RFC792], [RFC4443]) or RSVP [RFC2205]
   protocols could be used for delivering the Quick-Start Request.

B.1.1.  ICMP

   Being a control protocol used between Internet nodes, one could argue
   that ICMP is the ideal method for requesting permission for faster
   start-up from routers.  The ICMP header is above the IP header.
   Quick-Start could be accomplished with ICMP as follows: If the ICMP
   protocol is used to implement Quick-Start, the equivalent of the
   Quick-Start IP option would be carried in the ICMP header of the ICMP
   Quick-Start Request.  The ICMP Quick-Start Request would have to pass
   by the routers on the path to the receiver, possibly using the IP
   Router Alert option [RFC2113].  A router that approves the Quick-
   Start Request would take the same actions as in the case with the
   Quick-Start IP Option, and forward the packet to the next router
   along the path.  A router that does not approve the Quick-Start
   Request, even with a decreased value for the Requested Rate, would
   delete the ICMP Quick-Start Request, and send an ICMP Reply to the
   sender that the request was not approved.  If the ICMP Reply was
   dropped in the network, and did not reach the receiver, the sender
   would still know that the request was not approved from the absence
   of feedback from the receiver.  If the ICMP Quick-Start Request was
   dropped in the network due to congestion, the sender would assume
   that the request was not approved.  The ICMP message would need the
   source and destination port numbers for demultiplexing at the end
   nodes.  If the ICMP Quick-Start Request reached the receiver, the
   receiver would use transport-level or application-level mechanisms to
   send a response to the sender, exactly as with the IP Option.

   One benefit of using ICMP would be that the delivery of the TCP SYN
   packet or other initial packet would not be delayed by IP option
   processing at routers.  A greater advantage is that if middleboxes
   were blocking packets with Quick-Start Requests, using the Quick-
   Start Request in a separate ICMP packet would mean that the middlebox
   behavior would not affect the connection as a whole.  (To get this
   robustness to middleboxes with TCP using an IP Quick-Start Option,
   one would have to have a TCP-level Quick-Start Request packet that
   could be sent concurrently with, but separately from, the TCP SYN
   packet.)

   However, there are a number of disadvantages to using ICMP.  Some
   firewalls and middleboxes may not forward the ICMP Quick-Start
   Request packets.  (If an ICMP Reply packet from a router to the
   sender is dropped in the network, the sender would still know that
   the request was not approved, as stated earlier, so this would not be
   as serious of a problem.)  In addition, it would be difficult, if not
   impossible, for a router in the middle of an IP tunnel to deliver an
   ICMP Reply packet to the actual source, for example, when the inner
   IP header is encrypted, as in IPsec ESP tunnel mode [RFC4301].
   Again, however, the ICMP Reply packet would not be essential to the
   correct operation of ICMP Quick-Start.

   Unauthenticated out-of-band ICMP messages could enable some types of
   attacks by third-party malicious hosts that are not possible when the
   control information is carried in-band with the IP packets that can
   only be altered by the routers on the connection path.  Finally, as a
   minor concern, using ICMP would cause a small amount of additional
   traffic in the network, which is not the case when using IP options.

B.1.2.  RSVP

   With some modifications, RSVP [RFC2205] could be used as a bearer
   protocol for carrying the Quick-Start Requests.  Because routers are
   expected to process RSVP packets more extensively than the normal
   transport protocol IP packets, delivering a Quick-Start rate request
   using an RSVP packet would seem an appealing choice.  However, Quick-
   Start with RSVP would require a few differences from the conventional
   usage of RSVP.  Quick-Start would not require periodical refreshing
   of soft state, because Quick-Start does not require per-connection
   state in routers.  Quick-Start Requests would be transmitted
   downstream from the sender to receiver in the RSVP Path messages,
   which is different from the conventional RSVP model where the
   reservations originate from the receiver.  Furthermore, the Quick-
   Start Response would be sent using the transport-level or
   application-level mechanisms, instead of using the RSVP Resv message.

   If RSVP was used for carrying a Quick-Start Request, a new "Quick-
   Start Request" class object would be included in the RSVP Path
   message that is sent from the sender to receiver.  The object would
   contain the rate request field in addition to the common length and
   type fields.  The Send_TTL field in the RSVP common header could be
   used as the equivalent of the QS TTL field.  The Quick-Start capable
   routers along the path would inspect the Quick-Start Request object
   in the RSVP Path message, decrement Send_TTL, and adjust the rate
   request field if needed.  If an RSVP router did not understand the
   Quick-Start Request object, it would reject the entire RSVP message
   and send an RSVP PathErr message back to the sender.  When an RSVP
   message with the Quick-Start Request object reaches the receiver, the

   receiver sends a Quick-Start Reply message in the corresponding
   transport protocol header in the same way as described in the context
   of IP options earlier.  If the RSVP message with the Quick-Start
   Request object was dropped along the path, the transport sender would
   simply proceed with the normal congestion control procedures.

   Much of the discussion about benefits and drawbacks of using ICMP for
   making the Quick-Start Request also applies to the RSVP case.  If the
   Quick-Start Request was transmitted in a separate packet instead of
   as an IP option, the transport protocol packet delivery would not be
   delayed due to IP option processing at the routers, and the initial
   transport packets would reach their destination more reliably.  The
   possible disadvantages of using ICMP and RSVP are also expected to be
   similar: middleboxes in the network may not be able to forward the
   Quick-Start Request messages, and the IP tunnels might cause problems
   for processing the Quick-Start Requests.

B.2.  Alternate Encoding Functions

   In this section, we look at alternate encoding functions for the Rate
   Request field in the Quick-Start Request.  The main requirements for
   this function is that it should have a sufficiently wide range for
   the requested rate.  There is no need for overly fine-grained
   precision in the requested rate.  Similarly, while it would be
   attractive for the encoding function to be easily computable, it is
   also possible for end-nodes and routers to simply store the table
   giving the mapping between the value N in the Rate Request field, and
   the actual rate request f(N).  In this section, we consider possible
   encoding methods for Rate Request fields of different sizes,
   including four-bit, eight-bit, and larger Rate Request fields.

   Linear functions:
   One possible proposal would be for the Rate Request field to be
   formatted in bits per second, scaled so that one unit equals M Kbps,
   for some fixed value of M.  Thus, for the value N in the Rate Request
   field, the requested rate would be M*N Kbps.

   Powers of two:
   If a granularity of factors of two is sufficient for the Rate
   Request, then the encoding function with the most range would be for
   the requested rate to be K*2^N; for N, the value in the Rate Request
   field; and for K, some constant.  For N=0, the rate request would be
   set to zero, regardless of the encoding function.  For example, for
   K=40,000 and an eight-bit Rate Request field, the request range would
   be from 80 Kbps to 40*2^255 Kbps.  This clearly would be an
   unnecessarily large request range.

   For a four-bit Rate Request field, the upper limit on the rate
   request is 1.3 Gbps.  It seems to us that an upper limit of 1.3 Gbps
   would be fine for the Quick-Start rate request, and that connections
   wishing to start up with a higher initial sending rate should be
   encouraged to use other mechanisms, such as the explicit reservation
   of bandwidth.  If an upper limit of 1.3 Gbps was not acceptable, then
   five or six bits could be used for the Rate Request field.

   The lower limit of 80 Kbps could be useful for flows with round-trip
   times of a second or more.  For a flow with a round-trip time of one
   second, as is typical in some wireless networks, the TCP initial
   window of 4380 bytes allowed by [RFC3390] (given appropriate packet
   sizes) would translate to an initial sending rate of 35 Kbps.  Thus,
   for TCP flows, a rate request of 80 Kbps could be useful for some
   flows with large round-trip times.

   The lower limit of 80 Kbps could also be useful for some non-TCP
   flows that send small packets, with at most one small packet every 10
   ms.  A rate request of 80 Kbps would translate to a rate of a hundred
   100-byte packets per second (including packet headers).  While some
   small-packet flows with large round-trip times might find a smaller
   rate request of 40 Kbps to be useful, our assumption is that a lower
   limit of 80 Kbps on the rate request will be generally sufficient.
   Again, if the lower limit of 80 kbps was not acceptable, then extra
   bits could be used for the Rate Request field.

   If the granularity of factors of two was too coarse, then the
   encoding function could use a base less than two.  An alternate form
   for the encoding function would be to use a hybrid of linear and
   exponential functions.

   A mantissa and exponent representation:
   Section 4.4 of [B05] suggests a mantissa and exponent representation
   for the Quick-Start encoding function.  With e and f as the binary
   numbers in the exponent and mantissa fields, and with 0 <= f < 1,
   this would represent the rate (1+f)*2^e.  [B05] suggests a mantissa
   field for f of 8, 16, or 24 bits, with an exponent field for e of 8
   bits.  This representation would allow larger rate requests, with an
   encoding that is less coarse than the powers-of-two encoding used in
   this document.

   Constraints of the transport protocol:
   We note that the Rate Request is also constrained by the abilities of
   the transport protocol.  For example, for TCP with Window Scaling,
   the maximum window is at most 2**30 bytes.  For a TCP connection with
   a long, 1 second round-trip time, this would give a maximum sending
   rate of 1.07 Gbps.

B.3.  The Quick-Start Request: Packets or Bytes?

   One of the design questions is whether the Rate Request field should
   be in bytes per second or in packets per second.  We discuss this
   separately from the perspective of the transport, and from the
   perspective of the router.

   For TCP, the results from the Quick-Start Request are translated into
   a congestion window in bytes, using the measured round-trip time and
   the MSS.  This window applies only to the bytes of data payload, and
   does not include the bytes in the TCP or IP packet headers.  Other
   transport protocols would conceivably use the Quick-Start Request
   directly in packets per second, or could translate the Quick-Start
   Request to a congestion window in packets.

   The assumption of this document is that the router only approves the
   Quick-Start Request when the output link is significantly
   underutilized.  For this, the router could measure the available
   bandwidth in bytes per second, or could convert between packets and
   bytes by some mechanism.

   If the Quick-Start Request was in bytes per second, and applied only
   to the data payload, then the router would have to convert from bytes
   per second of data payload, to bytes per second of packets on the
   wire.  If the Rate Request field was in bytes per second, and the
   sender ended up using very small packets, this could translate to a
   significantly larger number in terms of bytes per second on the wire.
   Therefore, for a Quick-Start Request in bytes per second, it makes
   most sense for this to include the transport and IP headers as well
   as the data payload.  Of course, this will be, at best, a rough
   approximation on the part of the sender; the transport-level sender
   might not know the size of the transport and IP headers in bytes, and
   might know nothing at all about the separate headers added in IP
   tunnels downstream.  This rough estimate seems sufficient, however,
   given the overall lack of fine precision in Quick-Start
   functionality.

   It has been suggested that the router could possibly use information
   from the MSS option in the TCP packet header of the SYN packet to
   convert the Quick-Start Request from packets per second to bytes per
   second, or vice versa.  This would be problematic for several
   reasons.  First, if IPsec is used, the TCP header will be encrypted.
   Second, the MSS option is defined as the maximum MSS that the TCP
   sender expects to receive, not the maximum MSS that the TCP sender
   plans to send [RFC793].  However, it is probably often the case that
   this MSS also applies as an upper bound on the MSS used by the TCP
   sender in sending.

   We note that the sender does not necessarily know the Path MTU when
   the Quick-Start Request is sent, or when the initial window of data
   is sent.  Thus, with IPv4, packets from the initial window could end
   up being fragmented in the network if the "Don't Fragment" (DF) bit
   is not set [RFC1191].  A Rate Request in bytes per second is
   reasonably robust to fragmentation.  Clearly, a Rate Request in
   packets per second is less robust in the presence of fragmentation.
   Interactions between larger initial windows and Path MTU Discovery
   are discussed in more detail in RFC 3390 [RFC3390].

   For a Quick-Start Request in bytes per second, the transport senders
   would have the additional complication of estimating the bandwidth
   usage added by the packet headers.

   We have chosen a Rate Request field in bytes per second rather than
   in packets per second because it seems somewhat more robust,
   particularly to routers.

B.4.  Quick-Start Semantics: Total Rate or Additional Rate?

   For a Quick-Start Request sent in the middle of a connection, there
   are two possible semantics for the Rate Request field, as follows:

   (1) Total Rate: The requested Rate Request is the requested total
       rate for the connection, including the current rate; or

   (2) Additional Rate: The requested Rate Request is the requested
       increase in the total rate for that connection, over and above
       the current sending rate.

   When the Quick-Start Request is sent after an idle period, the
   current sending rate is zero, and there is no difference between (1)
   and (2) above.  However, a Quick-Start Request can also be sent in
   the middle of a connection that has not been idle, e.g., after a
   mobility event, or after an application-limited period when the
   sender is suddenly ready to send at a much higher rate.  In this
   case, there can be a significant difference between (1) and (2)
   above.  In this section, we consider briefly the tradeoffs between
   these two options, and explain why