--- 1/draft-ietf-tsvwg-quickstart-06.txt 2006-10-09 22:12:49.000000000 +0200 +++ 2/draft-ietf-tsvwg-quickstart-07.txt 2006-10-09 22:12:49.000000000 +0200 @@ -1,18 +1,18 @@ Internet Engineering Task Force S. Floyd INTERNET-DRAFT M. Allman -draft-ietf-tsvwg-quickstart-06.txt ICIR -Expires: February 2007 A. Jain +draft-ietf-tsvwg-quickstart-07.txt ICIR +Expires: April 2007 A. Jain F5 Networks P. Sarolahti Nokia Research Center - 30 August 2006 + 9 October 2006 Quick-Start for TCP and IP Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -25,21 +25,21 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 2007. + This Internet-Draft will expire on April 2007. Abstract This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and at times in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is @@ -58,26 +58,42 @@ by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: + Changes from draft-ietf-tsvwg-quickstart-06: + + * Changes in reponse to the review from the + General Area Review Team: + - Added text to Overview about the role of TCP feedback. + - Updated the flow label discussion from RFC2460 to RFC3697. + - Instead of saying that the router SHOULD remove the QS Option + when denying a request, but MAY zero fields instead, + said that the router SHOULD either remove the QS option + or zero the fields. + - Fixed typos and clarified some text. + + * Still needs feedback from the ipv6 or v6ops community; + - perhaps also have IPv6 people read the discussion of + end-point address changes in Section 4.1. + Changes from draft-ietf-tsvwg-quickstart-05: * Minor editing in response to AD feedback from Lars Eggert. This includes changing one "should" to "SHOULD", - and changing formating of the IANA Considerations + and changing formatting of the IANA Considerations section. * Clarifying in the Introduction that the QS router does not give preferential treatment to QS packets. In response to email from Fil Dickinson. * Added a discussion of interactions between Quick-Start and draft-ietf-pmtud-method. In response to AD Feedback from Lars Eggert. @@ -337,118 +355,118 @@ 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 21 3.3. Processing the Quick-Start Request at Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.1. Processing the Report of Approved Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26 4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 27 4.2. The Quick-Start Response Option in the TCP - header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 30 + header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 29 4.4. TCP: Receiving and Using the Quick-Start Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30 4.5. TCP: Controlling Acknowledgement Traffic on - the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 33 + the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 32 4.6. TCP: Responding to a Loss of a Quick-Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.7. TCP: A Quick-Start Request for a Larger Ini- - tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 4.7.1. Interactions with Path MTU Discovery. . . . . . . . 35 + tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 4.7.1. Interactions with Path MTU Discovery. . . . . . . . 34 4.7.2. Quick-Start Request Packets that are - Discarded by Routers or Middleboxes. . . . . . . . . . . . 36 + Discarded by Routers or Middleboxes. . . . . . . . . . . . 35 4.8. TCP: A Quick-Start Request in the Middle of - a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 37 - 4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 38 - 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 39 + a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 36 + 4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 37 + 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 38 6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 39 6.1. Simple Tunnels That Are Compatible with Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.1.1. Simple Tunnels that are Aware of Quick- - Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 42 + Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.2. Simple Tunnels That Are Not Compatible with Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43 6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 44 7. The Quick-Start Mechanism in other Transport Pro- - tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 - 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 46 - 8.1. Determining the Rate to Request. . . . . . . . . . . . . 46 + tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 45 + 8.1. Determining the Rate to Request. . . . . . . . . . . . . 45 8.2. Deciding the Permitted Rate Request at a - Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 - 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 47 - 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 47 - 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 48 + Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 46 + 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 46 + 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 47 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49 - 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 50 - 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 50 + 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 49 + 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 49 9.4.2. Receivers Lying about Whether the Request was Approved . . . . . . . . . . . . . . . . . . . 51 9.4.3. Receivers Lying about the Approved Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 9.4.4. Collusion between Misbehaving Routers . . . . . . . 53 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54 - 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 55 + 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 54 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55 - 10. Implementation and Deployment Issues . . . . . . . . . . . . 56 + 10. Implementation and Deployment Issues . . . . . . . . . . . . 55 10.1. Implementation Issues for Sending Quick- Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56 10.2. Implementation Issues for Processing Quick- - Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 57 + Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57 10.4. A Comparison with the Deployment Problems - of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 - 11. Security Considerations. . . . . . . . . . . . . . . . . . . 59 + of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 + 11. Security Considerations. . . . . . . . . . . . . . . . . . . 58 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60 - 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 61 + 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 60 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61 A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62 A.1. Fast Start-ups without Explicit Information - from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 63 + from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 62 A.2. Optimistic Sending without Explicit Informa- tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64 A.3. Fast Start-ups with other Information from Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 A.4. Fast Start-ups with more Fine-Grained Feed- - back from Routers . . . . . . . . . . . . . . . . . . . . . . 66 + back from Routers . . . . . . . . . . . . . . . . . . . . . . 65 A.5. Fast Start-ups with Lower-Than-Best-Effort Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 - B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 67 + B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 66 B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67 B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67 - B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 69 - B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 70 + B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 68 + B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 69 B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 71 B.4. Quick-Start Semantics: Total Rate or Addi- - tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 73 + tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 72 B.5. Alternate Responses to the Loss of a Quick- - Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 74 + Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 73 B.6. Why Not Include More Functionality?. . . . . . . . . . . 74 B.7. Alternate Implementations for a Quick-Start Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 B.7.1. An Alternate Proposal for the Quick- - Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78 + Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 77 B.7.2. The Earlier Request-Approved Quick- Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78 C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79 - D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 81 + D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 80 E. Possible Additional Uses for the Quick-Start Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 - Normative References . . . . . . . . . . . . . . . . . . . . . . 84 + Normative References . . . . . . . . . . . . . . . . . . . . . . 83 Informative References . . . . . . . . . . . . . . . . . . . . . 84 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 91 - Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 91 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 90 + Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 90 1. Introduction Each connection begins with a question: "What is the appropriate sending rate for the current network path?" The question is not answered explicitly, but each TCP connection determines the sending rate by probing the network path and altering the congestion window (cwnd) based on perceived congestion. Each TCP connection starts with a pre-configured initial congestion window (ICW). Currently, TCP allows an initial window of between one and four MSS-sized @@ -595,49 +613,53 @@ with IP and TCP follows in Sections 3 and 4. Quick-Start could be used in the middle of a connection, e.g., after an idle or underutilized period, as well as for the initial sending rate; these uses of Quick-Start are discussed later in the document. Quick-Start requires end-points and routers to work together, with end-points requesting a higher sending rate in the Quick-Start (QS) option in IP, and routers along the path approving, modifying, discarding or ignoring (and therefore disallowing) the Quick-Start Request. The receiver uses reliable, transport-level mechanisms to - inform the sender of the status of the Quick-Start Request. In + inform the sender of the status of the Quick-Start Request. For + example, when TCP is used, the TCP receiver sends feedback to the + sender using a Quick-Start Response option in the TCP header. In addition, Quick-Start assumes a unicast, congestion-controlled transport protocol; we do not consider the use of Quick-Start for multicast traffic. When sent as a request, the Quick-Start Option includes a request for a sending rate in bits per second, and a Quick-Start TTL (QS TTL) to be decremented by every router along the path that understands the option and approves the request. The Quick-Start TTL is initialized by the sender to a random value. The transport receiver returns the rate, information about the TTL and the Quick- - Start Nonce to the sender using transport-level mechanisms. In - particular, the receiver computes the difference between the Quick- - Start TTL and the IP TTL (the TTL in the IP header) of the Quick- - Start request packet, and returns this in the Quick-Start response. - The sender uses this information to determine if all of the routers - along the path decremented the Quick-Start TTL, approving the Quick- - Start Request. + Start Nonce to the sender using transport-level mechanisms; for TCP, + the receiver sends this information in the Quick-Start Response in + the TCP header. In particular, the receiver computes the difference + between the Quick-Start TTL and the IP TTL (the TTL in the IP + header) of the Quick-Start request packet, and returns this in the + Quick-Start response. The sender uses the TTL difference to + determine if all of the routers along the path decremented the + Quick-Start TTL, approving the Quick-Start Request. If the request is approved by all of the routers along the path, then the TCP sender combines this allowed rate with the measurement of the round-trip time, and ends up with an allowed TCP congestion window. This window is sent rate-paced over the next round-trip time, or until an ACK packet is received. Figure 1 shows a successful use of Quick-Start, with the sender's IP layer and both routers along the path approving the Quick-Start - Request. In this example, Quick-Start is used by TCP to establish - the initial congestion window. + Request, and the TCP receiver using the Quick-Start Response to + return information to the TCP sender. In this example, Quick-Start + is used by TCP to establish the initial congestion window. Sender Router 1 Router 2 Receiver ------ -------- -------- -------- | | | | Quick-Start Request | in SYN or SYN/ACK. | IP: Decrement QS TTL | to approve request --> @@ -650,21 +672,22 @@ | Decrement | QS TTL | to approve | request --> | | | | | Return Quick-Start | info to sender in - | <-- TCP ACK packet. + | Quick-Start Response + | <-- in TCP ACK packet. | | | Quick-Start approved, | translate to cwnd. | Report Approved Rate. V Send cwnd paced over one RTT. --> Figure 1: A successful Quick-Start Request. Figure 2 shows an unsuccessful use of Quick-Start, with one of the @@ -691,21 +714,22 @@ | | Forward packet | without modifying | Quick-Start Option. --> | | | | | Return Quick-Start | info to sender in - | <-- TCP ACK packet. + | Quick-Start Response + | <-- in TCP ACK packet. | | | Quick-Start not approved. | Report Approved Rate. V Use default initial cwnd. --> Figure 2: An unsuccessful Quick-Start Request. 3. The Quick-Start Option in IP @@ -829,21 +853,21 @@ the network. If the packet contained the Quick-Start Request is acknowledged, but the acknowledgement packet does not contain a Quick-Start Response, then the sender MUST assume that the Quick- Start Request was denied, and set a Report of Approved Rate with a rate of zero. Routers may choose to ignore the Report of Approved Rate, or to use the Report of Approved Rate but ignore the QS Nonce. Alternately, some routers that use the Report of Approved Rate may choose to match the QS Nonce, masked by the approved rate, with the QS Nonce seen in the original request. - If the Rate Request is denied, the sender MUST sent a Report of + If the Rate Request is denied, the sender MUST send a Report of Approved Rate with the Rate Report field set to zero. We note that unlike a Quick-Start Request sent at the beginning of a connection, when a Quick-Start Request is sent in the middle of a connection, the connection could already have an established congestion window or sending rate. The Rate Request is the requested total rate for the connection, including the current rate of the connection; the Rate Request is *not* a request for an additional sending rate over and above the current sending rate. If the Rate Request is denied, or lowered to a value below the @@ -873,32 +897,26 @@ That is, TTL Diff MUST be calculated and stored as follows: TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2) Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does not require checksum re-calculation, because the IPv6 header does not have a checksum field, and modifying the Quick-Start Request in the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo- header checksum used in upper-layer checksum calculations. - Note that [RFC2460] specifies that when a specific flow label has - been assigned to packets, the contents of the Hop-by-Hop options, - excluding the next header field, must originate with the same - contents throughout the IP flow lifetime. However, the Quick-Start - option would be included in only a small fraction of the packets - during a flow lifetime. Thus, Quick-Start SHOULD NOT be used in an - IPv6 connection that uses flow labels unless the experimental - specification of flow labels in Appendix A of RFC 2460 is changed. - We note that RFC 2460 states that the use of the flow label field in - IPv6 "is, at the time of writing, still experimental and subject to - change as the requirements for flow support in the Internet become - clearer" [RFC2460]. + Appendix A of RFC 2460 requires that all packets with the same flow + label must be originated with the same hop-by-hop header contents, + which would be incompatible with Quick-Start. However, a later IPv6 + flow label specification [RFC3697] updates the use of flow labels in + IPv6 and removes this restriction. Therefore Quick-Start is + compatible with the current IPv6 specifications. 3.3. Processing the Quick-Start Request at Routers The Quick-Start Request does not report the current sending rate of the connection sending the request; in the default case of a router (or IP layer implementation at an end-node) that does not maintain per-flow state, a router makes the conservative assumption that the flow's current sending rate is zero. Each participating router can either terminate or approve the Quick-Start Request. A router MUST only approve a Quick-Start request if the output link is @@ -909,32 +927,30 @@ While the paragraph above defines the *semantics* of approving a Quick-Start request, this document does not specify the specific algorithms to be used by routers in processing Quick-Start Requests or Reports. This is similar to RFC 3168, which specifics the semantics of the ECN codepoints in the IP header, but does not specify specific algorithms for routers to use in deciding when to drop or mark packets before buffer overflow. A router that wishes to terminate the Quick-Start Request SHOULD - delete the Quick-Start Request from the IP header. This saves - resources because downstream routers will have no option to process. - If a Quick-Start-capable router wishes to deny the request but - doesn't delete the Quick-Start Request from the IP header, then the - router SHOULD zero the QS TTL, QS Nonce, and Rate Request fields. - Zeroing the Rate Request field may be more efficient for routers to - implement than deleting the Quick-Start option. As suggested in - [B05], future additions to Quick-Start could define error codes for - routers to insert into the QS Nonce field to report back to the - sender the reason that the Quick-Start request was denied, e.g., - that the router is denying all Quick-Start requests at this time, or - that this router as a matter of policy does not grant Quick-Start + either delete the Quick-Start Request from the IP header or zero the + QS TTL, QS Nonce, and Rate Request fields. Deleting the Quick-Start + Request saves resources because downstream routers will have no + option to process, but zeroing the Rate Request field may be more + efficient for routers to implement. As suggested in [B05], future + additions to Quick-Start could define error codes for routers to + insert into the QS Nonce field to report back to the sender the + reason that the Quick-Start request was denied, e.g., that the + router is denying all Quick-Start requests at this time, or that + this router as a matter of policy does not grant Quick-Start requests. A router that doesn't understand the Quick-Start option will simply forward the packet with the Quick-Start Request unchanged (ensuring that the TTL Diff will not match and Quick-Start will not be used). If the participating router has decided to approve the Quick-Start Request, it does the following: * The router MUST decrement the QS TTL by the amount the IP TTL is decremented (usually one). @@ -1057,21 +1073,21 @@ Rate K". Thus, the receiver has a 1/16 chance in successfully lying and saying that the received rate request was K+2 instead of K. We note that the protection offered by the QS Nonce is the same whether one router makes all of the decrements in the rate request, or whether they are made at different routers along the path. The requirements for randomization for the sender and routers in setting `random' values in the QS Nonce are not stringent - almost any form of pseudo-random numbers would do. The requirement is that - the original value for the QS Nonce is not easily guessable by the + the original value for the QS Nonce is not easily predictable by the receiver, and in particular, the nonce MUST NOT be easily determined from inspection of the rest of the packet or from previous packets. In particular, the nonce MUST NOT be based only on a combination of specific packet header fields. Thus, if two bits of the QS Nonce are changed by a router along the path, the receiver should not be able to guess those two bits from the other 28 bits in the QS Nonce. An additional requirement is that the receiver cannot be able to tell, from the QS Nonce itself, which numbers in the QS Nonce were generated by the sender, and which were generated by routers along @@ -1409,22 +1425,22 @@ acknowledgement traffic in DCCP's CCID2 [RFC4341]. In the absence of congestion control for acknowledgement traffic, the TCP receiver could limit its sending rate for ACK packets sent in response to Quick-Start data packets. The following information is needed by the TCP receiver: * The RTT: TCP naturally measures the RTT of the path and therefore should have a sample of the RTT. If the TCP receiver does not have a measurement of the round-trip time, it can use the time - between the receipt of the Quick-Start Request and the Quick-Start - Response packets. + between the receipt of the Quick-Start Request and the Report + of Approved Rate. * The Approved Rate Request (R): When the TCP receiver receives the Quick-Start Response packet, the receiver knows the value of the approved Rate Request. * The MSS: TCP advertises the MSS during the initial three-way handshake and therefore the receiver should have an understanding of the packet size the sender will be using. If the receiver does not have such an understanding or wishes to confirm the negotiated MSS, the size of the first data packet can be used. @@ -1657,47 +1673,47 @@ congestion window appropriately, and sets up rate-based pacing to be used with its initial window. If the Quick-Start Response is not valid, then Host B uses TCP's default initial window. In either case, Host B sends a Report of Approved Rate. 5. Quick-Start and IPsec AH This section shows that Quick-Start is compatible with IPsec AH (Authentication Header). AH uses an Integrity Check Value (ICV) in the IPsec Authentication Header to verify both message - authentication and integrity ([RFC2402], [RFC4302]). Changes to the + authentication and integrity ([RFC4302], page 85). Changes to the Quick-Start option in the IP header do not affect this AH ICV. The tunnel considerations in Section 6 below apply to all IPsec tunnels, regardless of what IPsec headers or processing are used in conjunction with the tunnel. Because the contents of the Quick-Start option can change along the path, it is important that these changes not affect the IPsec Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC - 2402 requires that unrecognized IPv4 options be zeroed for AH ICV + 4302 requires that unrecognized IPv4 options be zeroed for AH ICV computation purposes, so Quick-Start IP Option data changing en route does not cause problems with existing IPsec AH implementations for IPv4. If the Quick-Start option is recognized, it MUST be treated as a mutable IPv4 option, and hence be completely zeroed for AH ICV calculation purposes. IPv6 option numbers explicitly indicate whether the option is mutable; the 3rd highest order bit in the IANA-allocated option type has the value 1 to indicate that the - Quick-Start option data can change en route. RFC 2402 requires that + Quick-Start option data can change en route. RFC 4302 requires that the option data of any such option be zeroed for AH ICV computation purposes. Therefore changes to the Quick-Start option in the IP header do not affect the calculation of the AH ICV. 6. Quick-Start in IP Tunnels and MPLS This section considers interactions between Quick-Start and IP - tunnels, including IPsec ([RFC2401], [RFC4301]), IP in IP [RFC2003], - GRE [RFC2784], and others. This section also considers interactions + tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE + [RFC2784], and others. This section also considers interactions between Quick-Start and MPLS [RFC3031]. In the discussion, we use TTL Diff, defined earlier as the difference between the IP TTL and the Quick-Start TTL, mod 256. Recall that the sender considers the Quick-Start request approved only if the value of TTL Diff for the packet entering the network is the same as the value of TTL Diff for the packet exiting the network. Simple tunnels: IP tunnel modes are generally based on adding a new @@ -1842,32 +1857,32 @@ Quick-Start, a valid Quick-Start Request with unchanged TTL Diff traverses in the inner header, while the outer header most likely does not carry a Quick-Start Request. If the tunnel egress also does not support Quick-Start, it remains possible that the Quick- Start Request would be falsely approved, because the packet is decapsulated using the Quick-Start request from the inner header, and the value of TTL Diff echoed to the sender remains unchanged. For example, such a scenario can occur with a Bump-In-The-Stack (BITS), an IPSec encryption implementation where the data encryption occurs between the network drivers and the TCP/IP protocol stack - [RFC2401]. + [RFC4301]. As one example, if a remote access VPN client uses a BITS structure, then Quick-Start obstacles between the client and the VPN gateway won't be seen. This is a particular problem because the path between the client and the VPN gateway is likely to contain the most congested part of the path. Because most VPN clients are reported to use BITS [H05], we will explore this in more detail. A Bump-In-The-Wire (BITW) is an IPSec encryption implementation where the encryption occurs on an outboard processor, offloading the - encryption processing overhead from the host or router [RFC2401]. + encryption processing overhead from the host or router [RFC4301]. The BITW device is usually IP addressable, which means that the IP TTL is decremented before the packet is passed to the BITW. If the QS TTL is not decremented, then the value of TTL Diff is changed, and the Quick-Start request will be denied. However, if the BITW supports a host and does not have its own IP address, then the IP TTL is not decremented before the packet is passed from the host to the BITW, and a false positive could occur. Other tunnels that need to be looked at are IP tunnels over non- network protocols, such as IP over TCP and IP over UDP [RFC3948], @@ -2431,21 +2446,21 @@ significantly when Quick-Start was deployed in a controlled environment such as an Intranet, where there was some form of centralized control over the users in the system. We also note that this form of attack could potentially make Quick-Start unusable, but it would not do any further damage; in the worst case, the network would function as a network without Quick-Start. [SAF06] considers the potential of Extreme Quick-Start algorithms at routers, which keep per-flow state for Quick-Start connections, in protecting the availability of Quick-Start bandwidth in the face of - frequent overly-larqe Quick-Start requests. + frequent overly-large Quick-Start requests. 9.7. Simulations with Quick-Start Quick-Start was added to the NS simulator [SH02] by Srikanth Sundarrajan, and additional functionality was added by Pasi Sarolahti. The validation test is at `test-all-quickstart' in the `tcl/test' directory in NS. The initial simulation studies from [SH02] show a significant performance improvement using Quick-Start for moderate-sized flows (between 4KB and 128KB) in under-utilized environments. These studies are of file transfers, with the @@ -2629,24 +2644,24 @@ of Quick-Start it does not endanger the network as a whole since TCP uses standard congestion control if Quick-Start is not available. Section 4.7.2 discusses the potential problem of packets with Quick- Start Requests dropped by middleboxes along the path. As discussed in Section 5, for IPv4 IPsec Authentication Header Integrity Check Value (AH ICV) calculation, the Quick-Start option is a mutable IPv4 option, and hence completely zeroed for AH ICV calculation purposes; this is also the treatment required by RFC - 2402 for unrecognized IPv4 options. The IPv6 Quick-Start option's + 4302 for unrecognized IPv4 options. The IPv6 Quick-Start option's IANA-allocated option type indicates that it is a mutable option, - hence, according to RFC 2402, its option data is required to be - zeroed for AH ICV computation purposes. See RFC 2402 for further + hence, according to RFC 4302, its option data is required to be + zeroed for AH ICV computation purposes. See RFC 4302 for further explanation. Section 6.2 discusses possible problems of Quick-Start used by connections carried over simple tunnels that are not compatible with Quick-Start. In this case it is possible that a Quick-Start Request is erroneously considered approved by the sender without the routers in the tunnel having individually approved the request, causing a false positive. We note two high-order points here. First, the Quick-Start Nonce @@ -2865,21 +2880,21 @@ (2) Congestion collapse: There could also be concerns about congestion collapse if many flows used large initial windows, many packets were dropped from optimistic initial windows, and many congested links ended up carrying packets that are only going to be dropped downstream. (3) Distributed Denial of Service attacks: A third question would be the potential role of optimistic senders in amplifying the damage done by a Distributed Denial of Service - (DDoS) attack (assuming attackers use conformant congestion control + (DDoS) attack (assuming attackers use compliant congestion control in the hopes of "flying under the radar"). (4) Performance hits if a packet is dropped: A fourth issue would be to quantify the performance hit to the connection when a packet is dropped from one of the initial windows. A.3. Fast Start-ups with other Information from Routers There have been several proposals somewhat similar to Quick-Start, where the transport protocol collects explicit information from the @@ -3010,32 +3024,31 @@ 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 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 tunnel mode [RFC2401]. - Again, however, the ICMP Reply packet would not be essential to the - correct operation of ICMP Quick-Start. + 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 @@ -3120,21 +3133,21 @@ 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 RFC 3390 (given appropriate packet + 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 @@ -3198,25 +3211,28 @@ 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. 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. + 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]. @@ -3634,21 +3650,21 @@ Second, we define the "target" algorithm for processing incoming Quick-Start Rate Requests (also from [SAF06]). The algorithm relies on knowing the bandwidth of the outgoing link (which in many cases can be easily configured), the utilization of the outgoing link (from an estimation technique such as given above) and an estimate of the potential bandwidth from recent Quick-Start approvals. Tracking the potential bandwidth from recent Quick-Start approvals is another case where local policy dictates how it should be done. - The simpliest method, outlined in Section 8.2, is for the router to + 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 @@ -3784,26 +3800,20 @@ October 1996. [RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997. [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. April 1997. [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. RFC 2205, September 1997. - [RFC2401] S. Kent and R. Atkinson, Security Architecture for the - Internet Protocol, RFC 2401, November 1998. - - [RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC - 2402, November 1998. - [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), RFC 2409, November 1998. [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased Initial TCP Window Size. RFC 2415. September 1998. [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 2463, December 1998. @@ -3836,20 +3846,23 @@ [RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful. RFC 3360, August 2002. [RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC 3649, December 2003. [RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per- Domain Behavior (PDB) for Differentiated Services. RFC 3662, December 2003. + [RFC3697] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering. IPv6 + Flow Label Specification. RFC 3697, March 2004. + [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775, June 2004. [RFC3819] P. Karn et al., "Advice for Internet Subnetwork Designers", July 2004. [RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January 2005. @@ -4031,21 +4045,21 @@ Pasi Sarolahti Nokia Research Center P.O. Box 407 FI-00045 NOKIA GROUP Finland Phone: +358 50 4876607 Email: pasi.sarolahti@iki.fi Full Copyright Statement - Copyright (C) The Internet Society 2006. This document is subject + Copyright (C) The Internet Society (2006). 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 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.