RFC 4782
Quick-Start for TCP and IP
Quick-Start for TCP and IP 🚀
Okay bestie, this is RFC 4782 🎀, and it's called "Quick-Start for TCP and IP" 💖. It came out of the Network Working Group in January 2007 🌸. The category is Experimental 🧪. The authors are S. Floyd and M. Allman from ICIR, A. Jain from F5 Networks, and P. Sarolahti from Nokia Research Center 👑. The title block doesn't list anything it obsoletes or updates 🙈.
Status of This Memo 📜✨
So this memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind, so it's more of an experiment than a rule 💅. The authors are really asking for discussion and suggestions for improvement 🫶. Distribution of this memo is unlimited too 🌈.
Copyright Notice 💜
Copyright (C) The IETF Trust (2007).
Abstract 💖
Okay, the abstract is the main event 💅. This document specifies an optional Quick-Start mechanism for transport protocols 🦋. It works together with routers 🌈 to figure out an allowed sending rate right at the start of a data transfer, and at times in the middle of one too (like after an idle period 😴). Quick-Start is designed to work with a range of transport protocols, but this document only specifies it for TCP 💜. The whole point is letting connections use higher sending rates when there's significant unused bandwidth along the path ✨. That only happens if the sender and all of the routers along the path approve the Quick-Start Request 🔥.
This document also describes many paths where Quick-Start Requests would not be approved 🙈. That includes all paths containing routers, IP tunnels, MPLS paths, and the like that don't support Quick-Start 💀. It also includes paths with routers or middleboxes that drop packets containing IP options. Requests could be hard to approve over multi-access layer-two networks too 😭.
Heads up: the document also covers environments where Quick-Start could fail with false positives 🫠. That's when the sender wrongly thinks the Quick-Start Request was approved by all of the routers along the path.
Because of all these concerns, and because of the difficulties and the seeming absence of motivation for routers (like core routers) to deploy Quick-Start 💅, Quick-Start is being proposed as a mechanism for controlled environments 🧚. It is not meant or appropriate for ubiquitous deployment in the global Internet 🌍.
Table of Contents 📚
1. Introduction ....................................................4
1.1. Conventions and Terminology ................................5
2. Assumptions and General Principles ..............................6
2.1. Overview of Quick-Start ....................................7
3. The Quick-Start Option in IP ...................................10
3.1. The Quick-Start Option for IPv4 ...........................10
3.2. The Quick-Start Option for IPv6 ...........................13
3.3. Processing the Quick-Start Request at Routers .............14
3.3.1. Processing the Report of Approved Rate .............15
3.4. The QS Nonce ..............................................16
4. The Quick-Start Mechanisms in TCP ..............................18
4.1. Sending the Quick-Start Request ...........................19
4.2. The Quick-Start Response Option in the TCP header .........20
4.3. TCP: Sending the Quick-Start Response .....................21
4.4. TCP: Receiving and Using the Quick-Start Response Packet ..22
4.5. TCP: Controlling Acknowledgement Traffic on the
Reverse Path ..............................................24
4.6. TCP: Responding to a Loss of a Quick-Start Packet .........26
4.7. TCP: A Quick-Start Request for a Larger Initial Window ....26
4.7.1. Interactions with Path MTU Discovery ...............26
4.7.2. Quick-Start Request Packets that are
Discarded by Routers or Middleboxes ................27
4.8. TCP: A Quick-Start Request in the Middle of a Connection ..28
4.9. An Example Quick-Start Scenario with TCP ..................29
5. Quick-Start and IPsec AH .......................................30
6. Quick-Start in IP Tunnels and MPLS .............................31
6.1. Simple Tunnels that Are Compatible with Quick-Start .......33
6.1.1. Simple Tunnels that Are Aware of Quick-Start .......33
6.2. Simple Tunnels that Are Not Compatible with Quick-Start ...34
6.3. Tunnels That Support Quick-Start ..........................35
6.4. Quick-Start and MPLS ......................................35
7. The Quick-Start Mechanism in Other Transport Protocols .........36
8. Using Quick-Start ..............................................37
8.1. Determining the Rate to Request ...........................37
8.2. Deciding the Permitted Rate Request at a Router ...........37
9. Evaluation of Quick-Start ......................................38
9.1. Benefits of Quick-Start ...................................38
9.2. Costs of Quick-Start ......................................39
9.3. Quick-Start with QoS-Enabled Traffic ......................41
9.4. Protection against Misbehaving Nodes ......................41
9.4.1. Misbehaving Senders ................................41
9.4.2. Receivers Lying about Whether the Request
was Approved .......................................43
9.4.3. Receivers Lying about the Approved Rate ............43
9.4.4. Collusion between Misbehaving Routers ..............44
9.5. Misbehaving Middleboxes and the IP TTL ....................46
9.6. Attacks on Quick-Start ....................................46
9.7. Simulations with Quick-Start ..............................47
10. Implementation and Deployment Issues ..........................47
10.1. Implementation Issues for Sending Quick-Start Requests ...47
10.2. Implementation Issues for Processing Quick-Start
Requests .................................................48
10.3. Possible Deployment Scenarios ............................48
10.4. A Comparison with the Deployment Problems of ECN .........50
11. Security Considerations .......................................50
12. IANA Considerations ...........................................52
12.1. IP Option ................................................52
12.2. TCP Option ...............................................52
13. Conclusions ...................................................53
14. Acknowledgements ..............................................53
Appendix A. Related Work ..........................................54
A.1. Fast Start-Ups without Explicit Information from Routers ..54
A.2. Optimistic Sending without Explicit Information from
Routers ...................................................56
A.3. Fast Start-Ups with Other Information from Routers ........56
A.4. Fast Start-Ups with More Fine-Grained Feedback from
Routers ...................................................57
A.5. Fast Start-ups with Lower-Than-Best-Effort Service ........58
Appendix B. Design Decisions ......................................59
B.1. Alternate Mechanisms for the Quick-Start Request:
ICMP and RSVP .............................................59
B.1.1. ICMP ...............................................59
B.1.2. RSVP ...............................................60
B.2. Alternate Encoding Functions ..............................61
B.3. The Quick-Start Request: Packets or Bytes? ................63
B.4. Quick-Start Semantics: Total Rate or Additional Rate? .....64
B.5. Alternate Responses to the Loss of a Quick-Start Packet ...65
B.6. Why Not Include More Functionality? .......................66
B.7. Alternate Implementations for a Quick-Start Nonce .........69
B.7.1. An Alternate Proposal for the Quick-Start Nonce ....69
B.7.2. The Earlier Request-Approved Quick-Start Nonce .....69
Appendix C. Quick-Start with DCCP .................................70
Appendix D. Possible Router Algorithm .............................72
Appendix E. Possible Additional Uses for the Quick-Start ..........74
Normative References ..............................................75
Informative References ............................................751. Introduction ✨
Okay so every connection starts with one big question: "What is the appropriate sending rate for the current network path?" 🤔 Nobody actually answers it out loud. Instead, each TCP connection figures it out by poking at the path and changing its congestion window (cwnd) based on how congested things seem. 🦋 Every connection starts with a pre-configured initial congestion window (ICW). Right now TCP lets that initial window be anywhere from one to four segments of maximum segment size (MSS) ([RFC2581], [RFC3390]). Then the connection probes for available bandwidth using slow-start ([Jac88], [RFC2581]), doubling cwnd during each congestion-free round-trip time (RTT). 🌸
Slow-start can take forever, bestie, especially on networks with huge bandwidth or long delays --- 😭 It can take a bunch of RTTs before the connection is actually using the bandwidth that's available. For example, building cwnd up to N segments takes log_2(N) - 2 round-trip times, assuming an initial congestion window of 4 segments. For big file transfers this isn't a big deal, since slow-start is only a tiny slice of the total time. 💅 But for moderate-sized transfers, the whole thing can happen inside the slow-start phase, so it takes many RTTs when one or two might have been enough given the bandwidth actually available on the path. Not ideal, not cute. 🙈
A lot of work has already gone into picking the initial congestion window for TCP. RFC 3390 lets it be up to four segments, based on the MSS the connection uses [RFC3390]. Our core premise is that, in the current architecture, you'd need explicit feedback from every router along the path before best-effort connections could use initial windows way bigger than what [RFC3390] allows, assuming there's no other info about the path. 🧚
So with Quick-Start, a TCP host (let's call them host A) asks for its desired sending rate in bytes per second, using a Quick-Start Option in the IP header of a TCP packet. 🎀 Then each router along the path can approve the requested rate, lower it, or say the Quick-Start Request isn't approved. (Also, the "routers" in this document include the IP-layer processing of the Quick-Start Request at the sender, so don't forget the sender is in the mix too! 💖) Approving a request doesn't mean a router gives that connection's packets VIP treatment. It's just saying "I'm currently underutilized and I think I've got enough spare bandwidth for your requested rate." ✨ The Quick-Start mechanism can also tell if some routers along the path don't understand the Quick-Start Option, or just haven't agreed to the rate request. TCP host B then sends the final rate back to host A in a transport-level Quick-Start Response, inside an answering TCP packet. 🫶
If every router on the path approves the Quick-Start Request, the TCP host can send at up to the approved rate for one window of data. After that, the connection goes back to the usual default TCP congestion control mechanisms. 👑 If the request isn't approved, the sender just uses the default congestion control from the start. No drama, no cap. 💅
Quick-Start isn't the first time routers have talked to transport protocols about sending rates, btw. Explicit Congestion Notification (ECN) gives explicit congestion feedback from routers to transport protocols, based on the router spotting congestion before the buffer overflows [RFC3168]. Quick-Start is different: routers wouldn't use it to share congestion info. Instead, it's an optional way to give transport protocols permission to use higher sending rates, based on every router on the path figuring out whether its output links are significantly underutilized. 🌈
Here's the roadmap. Section 2 gives an overview of Quick-Start. The formal specs live in Sections 3, 4, 6.1.1, and 6.3. Section 3 covers Quick-Start for both IPv4 and IPv6, and Section 4 covers it for TCP. Section 6 is mostly a non-normative chat about how Quick-Start plays with IP tunnels and MPLS, but Sections 6.1.1 and 6.3 do specify behavior for IP tunnels that are Quick-Start aware. 💜
The rest of the document is non-normative, so it's more like tea and vibes. 🍓 Section 5 shows that Quick-Start is compatible with IPsec AH (Authentication Header). Section 7 has non-normative guidelines for specifying Quick-Start in other transport protocols. Section 8 talks about using Quick-Start in transport end-nodes and routers. Section 9 weighs the costs and benefits of Quick-Start, and Section 10 covers implementation and deployment issues. The appendices discuss related work, the Quick-Start design decisions, and possible router algorithms. 📚
1.1. Conventions and Terminology
Okay, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document should be read as described in [RFC2119]. 🎀 Those capital words are doing serious work, so keep an eye on them! 👀
2. Assumptions and General Principles 🦋
This section describes the assumptions and general principles behind the design of the Quick-Start mechanism. It's basically the "why" behind all the choices. 🧠
Assumptions:
- Okay so the data going in each direction of a connection goes through different queues, and maybe even different routers. 🔁 That means any mechanism for figuring out the allowed sending rate would have to run independently for each direction. 💖
- The path between the two endpoints is relatively stable, meaning the path used by the Quick-Start Request is generally the same one the Quick-Start packets use one round-trip time later. [ZDPS01] shows this assumption should be generally valid. ✨ However, [RFC3819] talks about a range of Bandwidth on Demand subnets that could change the path's characteristics over time, so it's not a total guarantee. 😬
- Any new mechanism has to be incrementally deployable, and it might not be supported by every router and/or end-host. 🌸 So any new mechanism has to be able to handle non-supporting routers or end-hosts without messing up the current Internet semantics. Quick-Start is incrementally deployable in that sense, but a Quick-Start Request can't be approved for a particular connection unless both end-nodes and every router along the path have been configured to support Quick-Start. 🙈
General Principles:
- Our core premise is that, in the current architecture, you'd need explicit feedback from every router along the path before best-effort connections could use initial windows significantly larger than what [RFC3390] allows, assuming there's no other info about the path. 💅 Yes, it's the same premise as before, and it's still the main vibe. 👑
- A router should only approve a Quick-Start Request if its output link is underutilized. Any other approach would either need per-flow state at the router, or it could create a (possibly temporary) queue at the router. 🚦
- No per-flow state should be required at the router. While per-flow state isn't required, we also don't rule out a router storing per-flow state to make Quick-Start decisions or to check for misbehaving nodes. 🔍 Flexible, but not mandatory. 🫶
2.1. Overview of Quick-Start ✨
okay bestie, let's do the big picture first 🦋 this section is non-normative, which just means it's the vibe check and not the official rulebook. The real rules for Quick-Start with IP and TCP show up in Sections 3 and 4 💅 Quick-Start can also get used in the middle of a connection, like after an idle or underutilized period, and not only for the initial sending rate. We'll get to those later in the doc 🌸
So the whole point is that Quick-Start lets end-points and routers team up 🫶 The sender asks for a higher sending rate using the Quick-Start (QS) option in IP. Then every router along the path gets a say. It can approve the request, modify it, discard it, or just ignore it (which, lowkey, means it's disallowed too) 💀 The receiver then uses reliable, transport-level mechanisms to tell the sender how things went. With TCP, that means the receiver sends feedback in a Quick-Start Response option in the TCP header 🎀 Also, Quick-Start is only for unicast, congestion-controlled transport protocols. Multicast traffic is not part of this story 🙈
Here's how the request works. The Quick-Start Option carries a request for a sending rate in bits per second, plus a Quick-Start Time to Live (QS TTL). Every router that understands the option and approves the request decrements that QS TTL 🧚 The sender sets the QS TTL to a random value to start. Then the receiver sends back the rate, info about the TTL, and the Quick-Start Nonce using transport-level stuff. For TCP, all of that rides in the Quick-Start Response in the TCP header ✨
Now for the clever part 🧠 The receiver takes the QS TTL and subtracts the IP TTL (the TTL in the IP header) from the Quick-Start Request packet. Then it sends that difference back in the Quick-Start Response. The sender checks the TTL difference to figure out whether every router on the path actually decremented the QS TTL. If they all did, the request is approved 👑 That's the whole mechanism, no cap 💖
If the request gets approved everywhere, the TCP sender takes the allowed rate, combines it with its round-trip time measurement, and ends up with an allowed TCP congestion window. Then it sends that window rate-paced over the next round-trip time, or until an ACK packet comes in first 🦋
Figure 1 is the happy path 🌈 Both routers approve, the sender's IP layer is in on it, and the TCP receiver uses the Quick-Start Response to send the info back. In this example, Quick-Start is used by TCP to set the initial congestion window 💅
Sender Router 1 Router 2 Receiver
------ -------- -------- --------
| <IP TTL: 63>
| <QS TTL: 91>
| <TTL Diff: 28>
| Quick-Start Request
| in SYN or SYN/ACK.
| IP: Decrement QS TTL
| to approve request -->
|
| Decrement
| QS TTL
| to approve
| request -->
|
| Decrement
| QS TTL
| to approve
| request -->
|
| <IP TTL: 60>
| <QS TTL: 88>
| <TTL Diff: 28>
| Return Quick-Start
| info to sender in
| Quick-Start Response
| <-- in TCP ACK packet.
|
| <TTL Diff: 28>
| 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 is the sad path 😭 One of the routers doesn't approve the request, so it just forwards the packet without touching the Quick-Start Option. The TTL difference ends up different, and the sender sees that the request wasn't approved. When that happens, the sender falls back to the default congestion control mechanisms for that transport protocol. That includes the default initial congestion window, the response to idle periods, and so on 🍓
Sender Router 1 Router 2 Receiver
------ -------- -------- --------
| <IP TTL: 63>
| <QS TTL: 91>
| <TTL Diff: 28>
| Quick-Start Request
| in SYN or SYN/ACK.
| IP: Decrement QS TTL
| to approve request -->
|
| Decrement
| QS TTL
| to approve
| request -->
|
| Forward packet
| without modifying
| Quick-Start Option. -->
|
| <IP TTL: 60>
| <QS TTL: 89>
| <TTL Diff: 29>
| Return Quick-Start
| info to sender in
| Quick-Start Response
| <-- in TCP ACK packet.
|
| <TTL Diff: 29>
| 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 🎀
3.1. The Quick-Start Option for IPv4 🎀
okay bestie, let's get into the IPv4 version 💖 this is what a Quick-Start Request looks like on the wire:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | QS TTL |
| | | 0000 |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Quick-Start Option for IPv4.
A Quick-Start Request.Byte one is the option field 🍓 and it packs together a one-bit copy flag, a 2-bit class field, and a 5-bit option number. Byte two is the length field, and it says the option is eight bytes long 📏
Byte three holds a four-bit Function field. If that Function field is "0000", the Quick-Start Option is a Rate Request, and the second half of byte three is a four-bit Rate Request field. Iconic layout, no notes 💅
For a Rate Request, byte four is the Quick-Start TTL (QS TTL) field. The sender MUST set the QS TTL field to a random value 🎲 Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount they decrement the IP TTL. (Quick reminder: as everywhere in this doc, we use router' loosely so it also covers the Quick-Start functionality at the IP layer on the sender side 🧚) The QS TTL` is how the sender figures out whether every router on the path actually understood and approved the Quick-Start option 👀
For a Rate Request, the transport sender MUST calculate and store the TTL Diff, which is the difference between the IP TTL value and the QS TTL value in the Quick-Start Request packet, like this:
TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)For a Rate Request, bytes 5-8 hold a 30-bit QS Nonce (more on that in Section 3.4) and a two-bit Reserved field 🌸 The sender SHOULD set the reserved field to zero, and routers and receivers SHOULD ignore the reserved field. The sender SHOULD also set the 30-bit QS Nonce to a random value 🎲
The sender sets the Rate Request to the rate it wants, including an estimate of the transport and IP header overhead ✨ The encoding function sets the request rate to K*2^N bps (bits per second), where N is the value in the Rate Request field and K is set to 40,000. When N=0, the rate request is zero, no matter what the encoding function says. Table 1 shows the whole mapping, and for that four-bit field the request range runs from 80 Kbps to 1.3 Gbps 📈 The other encodings that were considered for the Rate Request are in Appendix B.2 if you're curious 🦋
N Rate Request (in Kbps)
--- ----------------------
0 0
1 80
2 160
3 320
4 640
5 1,280
6 2,560
7 5,120
8 10,240
9 20,480
10 40,960
11 81,920
12 163,840
13 327,680
14 655,360
15 1,310,720
Table 1: Mapping from Rate Request Field to Rate Request in Kbps.Routers can also approve a Quick-Start Request at a lower rate, by lowering the Rate Request inside it 🫶 Section 4.2 covers the Quick-Start Response that goes from the TCP receiver back to the TCP sender, and Section 4.4 covers how the TCP sender works out whether its Quick-Start Request got approved 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | Not Used |
| | | 1000 | Report| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Quick-Start Option for IPv4.
Report of Approved Rate.If the Function field in byte three is "1000", the Quick-Start Option is a Report of Approved Rate 📣 Here the second four bits of byte three are the Rate Report field, formatted exactly like the Rate Request field in a Rate Request. For a Report of Approved Rate, byte four goes unused, and bytes 5-8 hold a 30-bit QS Nonce and a 2-bit Reserved field 🌈
After an approved Rate Request, the sender MUST report the Approved Rate. It does this with a Quick-Start Option set up as a Report of Approved Rate, with the Rate Report field set to the approved rate and the QS Nonce set to the one from the original Quick-Start Request 💅 The packet carrying that report MUST be either a control packet sent before the first Quick-Start data packet, or a Quick-Start Option in the first data packet itself. The Report of Approved Rate doesn't have to be sent reliably 🙈 For example, if the approved rate goes out in a separate control packet, the sender can't really know whether that control packet got dropped somewhere in the network. If the packet with the Quick-Start Request gets acknowledged but the acknowledgement doesn't contain a Quick-Start Response, then the sender MUST assume 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 it but ignore the QS Nonce. Or, some routers that use the Report of Approved Rate may choose to match the QS Nonce, masked by the approved rate, against the QS Nonce they saw in the original request 🔥
If the Rate Request is denied, the sender MUST send a Report of Approved Rate with the Rate Report field set to zero. Bestie, that's the whole denial flow 😭
Now the lowkey important bit: a Quick-Start Request sent in the middle of a connection is not the same as one sent at the very start 👑 The connection might already have a congestion window or sending rate set up. The Rate Request is the requested total rate for the connection, including the current rate, so it is not a request for extra sending rate on top of what's already going. If the Rate Request gets denied, or lowered to a value below the connection's current sending rate, then the sender ignores the request and goes back to the default congestion control mechanisms of the transport protocol 🫧
Using the Quick-Start Option doesn't require also using the Router Alert Option [RFC2113] 🌸
And one more thing for IPv4: changing the IP options at routers means the IP header checksum has to be recalculated 🧮
3.2. The Quick-Start Option for IPv6 🦋
The IPv6 version lives in the Hop-by-Hop Options extension header, which every network node along the communication path processes [RFC2460] 🌍 After the generic Hop-by-Hop Options header, the option format is identical to IPv4, with one difference: the Length field should leave out the common type and length fields in the option format, and be set to 6 bytes instead of 8 bytes 🍓
For a Quick-Start Request, the transport receiver compares the Quick-Start TTL with the IPv6 Hop Limit field to work out the TTL Diff 🧠 (The Hop Limit in IPv6 is the equivalent of the TTL in IPv4, so you know who's who 💜) To be precise, TTL Diff MUST be calculated and stored as follows:
TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)Unlike IPv4, changing or deleting the Quick-Start IPv6 Option doesn't need a checksum recalculation 🙌 That's because the IPv6 header has no checksum field, and editing the Quick-Start Request inside the IPv6 Hop-by-Hop options header doesn't touch the IPv6 pseudo-header checksum that upper-layer checksum calculations use ✨
Appendix A of RFC 2460 says that all packets with the same flow label must be originated with the same hop-by-hop header contents, which would clash with Quick-Start 🙃 But a later IPv6 flow label specification [RFC3697] updates how flow labels are used in IPv6 and removes that restriction. So Quick-Start is compatible with the current IPv6 specifications, and we love a plot twist that ends well 🎀
3.3. Processing the Quick-Start Request at Routers ✨
okay so the Quick-Start Request does NOT tell anyone how fast the connection that sent it is currently sending 🙈. so in the default case (a router, or an IP-layer implementation at an end-node, that doesn't keep per-flow state) the 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 underutilized, AND if the router judges that the output link will continue to be underutilized if this and earlier approved requests are used by the senders. otherwise, the router reduces or terminates the Quick-Start Request 🫶
while the paragraph above defines the semantics of approving a Quick-Start Request, this document doesn't specify the exact algorithms routers should use to process Quick-Start Requests or Reports 🧚 this is kinda like RFC 3168, which spells out what the ECN codepoints in the IP header mean, but doesn't tell routers how to decide when to drop or mark packets before buffer overflow. same energy, different job ✨
a router that wants to terminate the Quick-Start Request SHOULD 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 that routers insert into the QS Nonce field to tell the sender WHY the request got 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. and a router that doesn't understand the Quick-Start Option will just forward the packet with the Quick-Start Request unchanged (which makes sure the TTL Diff won't match, so Quick-Start won't 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).
- if the router is only willing to approve a Rate Request less than the one in the Quick-Start Request, then the router replaces the Rate Request with a smaller value. the router MUST NOT increase the Rate Request in the Quick-Start Request. if the router decreases the Rate Request, the router MUST also modify the QS Nonce, as described in Section 3.4.
- in IPv4, the router MUST update the IP header checksum.
if the router approves the Quick-Start Request, this approval SHOULD be taken into account in the router's decision to accept or reject subsequent Quick-Start Requests (for example, by using a variable that tracks the recent aggregate of accepted Quick-Start Requests). this is important because it makes sure the router only approves a Quick-Start Request when it judges that the output link will stay underutilized if this and earlier Quick-Start Requests are used by the senders 🌸
ALSO, the approval of a Quick-Start Request SHOULD NOT be used by the router to change how it treats the data packets arriving from this connection in the next few round-trip times 🙅♀️ so the approval doesn't give Quick-Start data packets any special treatment at that router. it's just the router saying "i believe the Quick-Start data packets from this connection won't change my current underutilized state" 💖
a non-participating router forwards the Quick-Start Request unchanged, WITHOUT decrementing the QS TTL. it still decrements the TTL field in the IP header, which is required for all routers [RFC1812]. because of this, the sender can detect that the Quick-Start Request wasn't understood or approved by all of the routers along the path 👑
a router that uses multipath routing for packets within a single connection MUST NOT approve a Quick-Start Request. this is talked about in more detail in Section 9.2 🔥
3.3.1. Processing the Report of Approved Rate
if the Quick-Start Option has the Function field set to "1000", then this is a Report of Approved Rate, not a Rate Request 🧁 the router MAY ignore such an option, and either way it MUST NOT modify the contents of the option for a Report of Approved Rate. BUT the router MAY use the Approved Rate report to check that the sender isn't lying about the approved rate 🕵️♀️ if the reported Approved Rate is higher than the rate the router actually approved for this connection in the previous round-trip time, then the router may put some policy in place for cheaters. for instance, the router MAY decide to deny future Quick-Start Requests from this sender, including, if desired, deleting Quick-Start Requests from future packets from this sender. Section 9.4.1 goes into more detail about misbehaving senders 💀 and from the Report of Approved Rate, the router can also learn if some of the downstream routers approved the Quick-Start Request for a smaller rate or denied the use of Quick-Start, and then adjust its bandwidth allocations accordingly 🎀
3.4. The QS Nonce 🔐
the QS Nonce protects the Quick-Start sender from receivers lying about the value of the Rate Request they received 🫣 this matters most when the receiver already knows the original Rate Request (like when the sender always asks for the same value and the receiver has a long history of talking to that sender). without the QS Nonce, nothing stops the receiver from reporting back a Rate Request of K when the Rate Request it actually received was less than K. not cool 😤
Table 2 gives the format for the 30-bit QS Nonce:
Bits Purpose
--------- ------------------
Bits 0-1: Rate 15 -> Rate 14
Bits 2-3: Rate 14 -> Rate 13
Bits 4-5: Rate 13 -> Rate 12
Bits 6-7: Rate 12 -> Rate 11
Bits 8-9: Rate 11 -> Rate 10
Bits 10-11: Rate 10 -> Rate 9
Bits 12-13: Rate 9 -> Rate 8
Bits 14-15: Rate 8 -> Rate 7
Bits 16-17: Rate 7 -> Rate 6
Bits 18-19: Rate 6 -> Rate 5
Bits 20-21: Rate 5 -> Rate 4
Bits 22-23: Rate 4 -> Rate 3
Bits 24-25: Rate 3 -> Rate 2
Bits 26-27: Rate 2 -> Rate 1
Bits 28-29: Rate 1 -> Rate 0Table 2: The QS Nonce.
the transport sender MUST initialize the QS Nonce to a random value. if the router reduces the Rate Request from rate K to rate K-1, then the router MUST set the field in the QS Nonce for "Rate K -> Rate K-1" to a new random value. similarly, if the router reduces the Rate Request by N steps, the router MUST set the 2N bits in the relevant fields in the QS Nonce to a new random value. and the receiver MUST report the QS Nonce back to the sender 💌
if the Rate Request wasn't decremented in the network, then the QS Nonce should have its original value. similarly, if the Rate Request was decremented by N steps in the network, and the receiver reports back a Rate Request of K, then the last 2K bits of the QS Nonce should have their original value 🧠
the receiver gets a 1/4 chance of cheating about each step change in the rate request. so if the rate request is reduced by two steps in the network, the receiver has a 1/16 chance of successfully reporting that the original request was approved, because that requires reporting the original value for the QS nonce. and if the rate request is reduced many steps in the network and the receiver gets a QS Option with a rate request of K, the receiver has a 1/16 chance of guessing the original values for the fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 -> Rate K". so the receiver has a 1/16 chance of successfully lying and saying the received rate request was K+2 instead of K 😭
the protection the QS Nonce offers is the same whether one router makes all the decrements in the rate request, or whether they happen at different routers along the path ✨
the randomization requirements for the sender and routers when setting `random' values in the QS Nonce aren't strict. almost any form of pseudo-random numbers will do 🎲 the requirement is that the original value of the QS Nonce isn't easily predictable by the receiver. in particular, the nonce MUST NOT be easily determined from inspecting the rest of the packet or from previous packets. and the nonce MUST NOT be based only on a combination of specific packet header fields. so if two bits of the QS Nonce get 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 🫶
one more thing: the receiver cannot be able to tell, from the QS Nonce itself, which numbers were generated by the sender and which were generated by routers along the path. this makes it harder for the receiver to infer the original rate request value, which makes it one step harder for the receiver to cheat 🙈
Section 9.4 also looks at receiver cheating in more detail 🌈
4. The Quick-Start Mechanisms in TCP ✨
okay bestie, this section is where we see how Quick-Start actually works inside TCP 💅 we'll sketch the whole vibe first and then get into the nitty-gritty in the subsections 🦋
so if a TCP sender (say, host A) wants to use Quick-Start, it puts the requested sending rate in bits per second, properly formatted, into the Quick-Start Option in the IP header of the TCP packet. that packet is called the Quick-Start Request packet 🎀 (we're gonna be a little loose with "packet" vs. "segment" here, no cap). when it's used for initial start-up, the Quick-Start Request packet can be either the SYN or the SYN/ACK packet, as shown in Figure 1 🌸 the requested rate includes an estimate for the transport and IP header overhead too, which is such a thoughtful detail 🥹 then the TCP receiver (say, host B) sends back the Quick-Start Response option in the TCP header, in the responding SYN/ACK packet or ACK packet. that one's called the Quick-Start Response packet, and it tells host A how their request went ✨
if the acknowledging packet doesn't have a Quick-Start Response, or it has one with the wrong value for the TTL Diff or the QS Nonce, then host A MUST assume that its Quick-Start request failed 💀 in that case host A sends a Report of Approved Rate with a Rate Report of zero, and falls back to TCP's default congestion control procedure. for initial start-up, host A uses the default initial congestion window ([RFC2581], [RFC3390]) 🫶
but if the returning packet does have a valid Quick-Start Response, host A uses the info in the response, plus its own round-trip time measurement, to work out the Quick-Start congestion window (QS-cwnd) 🔥 Quick-Start data packets are the data packets sent because a Quick-Start request succeeded, up until the first Quick-Start packet gets acknowledged. the sender also sends a Report of Approved Rate. now here's the main requirement: to use Quick-Start, the TCP host MUST use rate-based pacing [VH97] to transmit Quick-Start packets at the rate listed in the Quick-Start Response, at whatever level of granularity the sending host can manage 👑 the doc also notes that the limits of interrupt timing on computers can limit how well a TCP host can rate-pace its outgoing packets, which is so real 😭
the two TCP end-hosts can decide on their own whether they want to request Quick-Start. for example, host A could send a Quick-Start Request in the SYN packet, and host B could also send a Quick-Start Request in the SYN/ACK packet 🧚
4.1. Sending the Quick-Start Request
when a TCP sender sends a Quick-Start Request, it SHOULD send that request on a packet that needs an acknowledgement, like a SYN, SYN/ACK, or data packet 💖 in that case, if the packet gets acknowledged but there's no Quick-Start Response in it, the sender knows the Quick-Start Request was denied, and can send a Report of Approved Rate 🙈
Quick-Start isn't only for when a connection is first set up, either. there are a bunch of other moments where a transport protocol might want to issue a Rate Request ✨ first, a reminder: Quick-Start is a coarse-grained mechanism 🍓 its Rate Requests aren't meant for fine-grained control of the transport's sending rate. instead, the transport MAY issue a Rate Request when it has no info about the right sending rate, and the default congestion control mechanisms might be seriously underestimating that rate 🦋
here are the potential spots where Quick-Start might be useful:
(1) at or soon after connection initiation, when the transport has no clue about the capacity of the network path, as we said above 🌈 (a transport that uses TCP Control Block sharing [RFC2140], the Congestion Manager [RFC3124], or other mechanisms for sharing congestion information might not need Quick-Start to figure out an appropriate rate 💜)
(2) after an idle period, when the transport no longer has a validated estimate of the available bandwidth for this flow 🌸 (an example would be a persistent-HTTP connection when a new HTTP request comes in after an idle period 🫶)
(3) after a host has received explicit indications that one of the endpoints has moved its point of network attachment 🧚 this can happen because of an underlying mobility mechanism like Mobile IP ([RFC3344], [RFC3775]). some transports, like Steam Control Transmission Protocol (SCTP) [RFC2960], may be associated with multiple IP addresses and can switch addresses (and therefore network paths) mid-connection 😭 if the transport actually knows a network path has changed, the current sending rate might not be appropriate anymore, and the transport sender may use Quick-Start to probe the network and see if it can send at a higher rate. (alternatively, traditional slow-start should be used in this case when Quick-Start is not available 🍓)
(4) after an application-limited period, when the sender has only been using a small amount of its appropriate share of the network capacity and has no valid estimate of its fair share 🔥 in this case, Quick-Start may be an appropriate mechanism to check whether the sender can send at a higher rate 💅 for instance, think about an app that steadily swaps low-rate control messages and then suddenly needs to send a big pile of data 🎀
okay so, of all of the above, this document recommends that a TCP sender MAY attempt to use Quick-Start in cases (1) and (2) ✨ it is NOT RECOMMENDED that a TCP sender use Quick-Start for case (3) at the current time 🙅♀️ case (3) needs external notifications that aren't presently defined for TCP or other transport protocols. and finally, a TCP SHOULD NOT use Quick-Start for case (4) at the current time 💀 case (4) needs more thought and investigation about how the transport protocol could tell it's in a situation that would call for sending a Quick-Start Request 🧠
as a general guideline, a TCP sender SHOULD NOT request a sending rate larger than it can actually use over the next round-trip time of the connection (or over 100 ms, if the round-trip time isn't known) 🌷 the exception is when it's needed to round the desired sending rate up to the next-highest allowable request 🫶
in any circumstances, the sender MUST NOT make a QS request if it has already made a QS request within the most recent round-trip time 🛑 no spamming the network, bestie 😤
Section 4.7 talks about some of the issues with using Quick-Start at connection initiation, and Section 4.8 covers the issues that come up when Quick-Start is used to request a larger sending rate after an idle period 📚
4.2. The Quick-Start Response Option in the TCP header
to approve the use of Quick-Start, the TCP receiver responds to a Quick-Start Request with a Quick-Start Response, using the Quick-Start Response Option in the TCP header 💖 here's what TCP's Quick-Start Response option looks like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: The Quick-Start Response Option in the TCP Header.
the first byte of the Quick-Start Response option holds the option kind, which identifies it as a TCP option 🎀
the second byte holds the option length in bytes 🌈 the length field MUST be set to 8 bytes 💜
the third byte has a four-bit Reserved field, plus the four-bit allowed Rate Request, formatted just like in the Quick-Start Rate Request option ✨
the fourth byte of the TCP option holds the TTL Diff 🦋 the TTL Diff is the difference between the IP TTL and the QS TTL fields in the received Quick-Start Request packet, calculated using equation (1) or (2) (depending on whether IPv4 or IPv6 is in use) 🧮
bytes 5-8 of the TCP option hold the 30-bit QS Nonce and a two-bit Reserved field 🍓
now, there are limits on how big the Quick-Start Response Option can be, but an eight-byte Quick-Start Response Option should not be a problem 🫶 the TCP Options field can hold up to 40 bytes, and other TCP options that might show up in a SYN or SYN/ACK packet include Maximum Segment Size (four bytes), Time Stamp (ten bytes), Window Scale (three bytes), and Selective Acknowledgments Permitted (two bytes) 🌸
4.3. TCP: Sending the Quick-Start Response
an end host (say, host B) that receives an IP packet containing a Quick-Start Request passes the Quick-Start Request, along with the value in the IP TTL field, up to the receiving TCP layer 🧚
if the TCP host is willing to allow the Quick-Start Request, a Quick-Start Response option gets included in the TCP header of the matching acknowledgement packet 💖 the Rate Request in the Quick-Start Response option is set to the received value of the Rate Request in the Quick-Start Option, or to a lower value if the TCP receiver is only willing to allow a lower Rate Request 🔥 the TTL Diff in the Quick-Start Response is set to the difference between the IP TTL value and the QS TTL value, as given in equation (1) or (2) (depending on whether IPv4 or IPv6 is used) 🧮 and the QS Nonce in the Response is set to the received value of the QS Nonce in the Quick-Start Option 🌷
if an end host gets an IP packet with a Quick-Start Request that has a rate request of zero, that host SHOULD NOT send a Quick-Start Response 🛑
finally, the Quick-Start Response MUST NOT be resent if it gets lost in the network 🙈 packet loss could mean there's congestion on the return path, and in that case it's better not to approve the Quick-Start Request 💀
4.4. TCP: Receiving and Using the Quick-Start Response Packet 🫶
Okay so picture TCP host A. It sent a Quick-Start Request, and now a Quick-Start Response shows up tucked inside an acknowledgement. 💌 Host A's first move is to check that the response is actually valid. It's valid if it has the correct TTL Diff value and an equal or lower Rate Request than what was in the Quick-Start Request. Then, if the received Rate Request is K, the rightmost 2K bits of the QS Nonce have to match the ones sent in the request. If any of that fails, the Quick-Start Request failed, and host A MUST use the default TCP congestion window it would have used without Quick-Start. 😭 And if the nonce bits don't match for a received Rate Request of K, host A MUST NOT send any more Quick-Start Requests for the whole life of the connection. No cap, that's a hard rule. 🚫
Whether the Quick-Start Request worked out or not, the host receiving the Quick-Start Response MUST send a Report of Approved Rate. ✨ Same energy if the packet with the Quick-Start Request gets acked but that ack doesn't include a Quick-Start Response: the sender MUST send a Report of Approved Rate. 💅
If the TTL Diff and Rate Request checks pass and host A is going to use Quick-Start, it MUST start using it within one round-trip time of getting the Quick-Start Response, or within three seconds, whichever is smaller. ⏱️ To use it, the host sets its Quick-Start congestion window (counted in MSS-sized segments), QS-cwnd, like this:
QS-cwnd = (R * T) / (MSS + H) (3)
where R is the Rate Request in bytes per second, T is the measured
round-trip time in seconds, and H is the estimated TCP/IP header size
in bytes (e.g., 40 bytes).Now the math nerd bit. 🤓 The sender is allowed to send at R bytes per second including the packet headers, but only R*MSS/(MSS+H) bytes per second of actual application data. Equivalently, that's R*T*MSS/(MSS+H) bytes of application data per round-trip time. Honestly, so clean. 🧮
The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if QS-cwnd is greater than cwnd. Otherwise, QS-cwnd just gets ignored. 🙅♀️ If QS-cwnd does get used, the host sets a flag saying it's in Quick-Start mode. While it's in that mode, the TCP sender MUST use rate-based pacing to pace out its Quick-Start packets at the approved rate. 🎀 If, during Quick-Start mode, the TCP sender gets ACKs for packets that were sent before the mode started, those ACKs get processed as usual, following the default congestion control mechanisms. Quick-Start mode ends when the TCP host receives an ACK for one of the Quick-Start packets. 🦋
Here's where it gets lowkey clever. If the congestion window hasn't been fully used by the time the first ack ends Quick-Start mode, the congestion window gets decreased to whatever has actually been used so far. 🌸 This is needed because the sender's round-trip-time estimate, taken when the Quick-Start Response arrived, might be longer than the RTTs that come after it. That can happen because of delays at routers processing the IP Quick-Start Option, or because the receiver was slow to respond to the Quick-Start Request packet. 🐢 An overly big RTT estimate could make the sender turn the approved rate in bytes per second into a window that's bigger than it needs, so the first ACK for a Quick-Start packet shows up before the whole window has been used. So, when the TCP sender gets the first ACK for a Quick-Start packet, the sender MUST reduce the congestion window to the amount that has actually been used. 🔥
Example time! 🍓 Say a TCP sender has an approved Quick-Start Request of R KBps, B-byte packets including headers, and an RTT estimate of T seconds. It would turn that Rate Request into a congestion window of R*T/B packets, and send the Quick-Start packets paced at R KBps. But what if the real RTT is T/2 seconds instead of T? Then acks for Quick-Start packets start coming back after T/2 seconds. Following the paragraph above, the sender would shrink its window from R*T/B to about R*T/(B*2) packets, which is the number of packets actually needed to fill the pipe at R KBps. (Note: this is just an illustration. The congestion window is actually set to the amount of data sent before the ACK arrives, not based on the equations above.) 💡
Once Quick-Start mode is exited and the window has been adjusted if needed, the TCP sender goes back to the default congestion-control mechanisms and processes later incoming ACK packets the way those mechanisms say to. For example, if the sender was in slow-start before the Quick-Start Request, and no packets were lost or marked since then, the sender keeps going in slow-start after leaving Quick-Start mode, as allowed by ssthresh. 🧚
To add robustness, the TCP sender MUST use Limited Slow-Start [RFC3742] along with Quick-Start. 🛡️ With Limited Slow-Start, the sender limits how many packets the congestion window can grow by for one window of data during slow-start.
When Quick-Start is used at the start of a connection, and no packet marks or losses have been reported yet, the TCP host MAY use the reported Rate Request to set the slow-start threshold to a value it wants, for example some small multiple of the congestion window. 🎯 A possible future research topic is how the sender might change the slow-start threshold at the start of a connection so it doesn't overshoot the path capacity. (The initial value of ssthresh is allowed to be arbitrarily high, and some TCP implementations use the size of the advertised window for ssthresh [RFC2581].) 🌈
4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path 🌊
When a Quick-Start Request gets approved for a TCP sender, the resulting Quick-Start data traffic can cause a sudden spike in pure ACK packets on the reverse path. 📈 For example, take the largest Quick-Start Request, 1.3 Gbps. With a TCP sender using 1500-byte packets and a TCP receiver that uses delayed acknowledgements, acking every other packet, that could mean 17.3 Mbps of acknowledgement traffic on the reverse path. Yikes. 😳
One possibility, for large Quick-Start Requests, would be for TCP receivers to send Quick-Start Requests to ask for bandwidth for their acknowledgement traffic on the reverse path. 🤔 But imo the better approach is for TCP receivers to just control the rate at which they send acknowledgement traffic. The optimal future solution would involve explicit congestion control for TCP acknowledgement traffic, the way it's already done for acknowledgement traffic in DCCP's CCID2 [RFC4341]. 🧠
Without 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 receiver needs the following info:
- The RTT: TCP naturally measures the RTT of the path, so it should have an RTT sample. If the TCP receiver doesn't have a measurement of the round-trip time, it can use the time between receiving the Quick-Start Request and the Report of Approved Rate.
- The Approved Rate Request (R): When the TCP receiver gets the Quick-Start Response packet, it knows the value of the approved Rate Request.
- The MSS: TCP advertises the MSS during the initial three-way handshake, so the receiver should understand the packet size the sender will be using. If the receiver doesn't have that understanding, or wants to confirm the negotiated MSS, the size of the first data packet can be used.
With that info, the TCP receiver can restrict its sending rate for pure acknowledgment traffic to at most 100 pure ACK packets per RTT. It does this by sending at most one ACK for every K data packets, where the ACK Ratio K is set to R*RTT/(100*8*MSS). 🧮 The receiver acknowledges the first Quick-Start data packet, and then every K data packets after that. So for a pretty extreme case of R=1.3 Gbps, RTT=0.2 seconds, and MSS=1500 bytes, K would be 216, and the receiver would acknowledge every 216 data packets. 🙈 From [RFC2581], the ACK Ratio K should have a minimum value of two. When the ACK Ratio is greater than two, and the TCP sender receives acknowledgements that each acknowledge more than two data packets, the TCP sender may want to use rate-based pacing to control the burstiness of its outgoing data traffic. 🎢
Without explicit congestion control mechanisms, TCP end nodes can't figure out the packet drop rate for pure acknowledgement traffic. That's true with or without Quick-Start. 🤷♀️ However, the TCP receiver could limit how fast its sending rate for pure ACK packets increases, by at most doubling that rate from one round-trip time to the next. It would do this by halving the ACK Ratio each round-trip time. 📉
Note that the above is one particular mechanism that could be used to control the ACK stream. Future work that looks into this scheme and others in detail is encouraged. 🔬✨
4.6. TCP: Responding to a Loss of a Quick-Start Packet 💔
For TCP, a "Quick-Start packet" is one of the packets sent in the window right after a successful Quick-Start Request. 📦 After detecting the loss or ECN-marking of a Quick-Start packet, TCP MUST revert to the default congestion control procedures that would have been used if the Quick-Start Request hadn't been approved. For example, if Quick-Start is used to set the initial window, and a packet from that initial window gets lost or marked, then the TCP sender MUST slow-start with the default initial window it would have used if Quick-Start hadn't been used. 🐌 On top of reverting to the default congestion control mechanisms, the sender MUST take into account that the Quick-Start congestion window was too large. So the sender SHOULD decrease ssthresh to, at most, half the number of Quick-Start packets that were successfully transmitted. Appendix B.5 covers possible alternatives for responding to the loss of a Quick-Start packet. 📚
If a Quick-Start packet is lost or ECN-marked, the sender SHOULD NOT make future Quick-Start Requests for this connection. 🙅♀️
We should also note that ECN [RFC3168] MAY be used with Quick-Start. As is always the case with ECN, the sender's congestion control response to an ECN-marked Quick-Start packet is the same as its response to a dropped one. So with Quick-Start packets marked as experiencing congestion, it reverts to slow start. 🚦
4.7. TCP: A Quick-Start Request for a Larger Initial Window 🎀
Some of the issues with using Quick-Start are tied to the specific scenario it's used in. 🎬 This section covers the following issues that come up when Quick-Start is used by TCP to request a larger initial window: (1) interactions with Path MTU Discovery (PMTUD); and (2) Quick-Start Request packets that are discarded by middleboxes. 👀
4.7.1. Interactions with Path MTU Discovery 🎀
okay so this part is kinda messy 😭 when Quick-Start is used to ask for a big initial window, it has to play nicely with Path MTU Discovery. RFC 3390 already talked about some of these issues, and it said:
"When larger initial windows are implemented along with Path MTU Discovery [RFC1191], alternatives are to set the Don't Fragment' (DF) bit in all segments in the initial window, or to set the Don't Fragment' (DF) bit in one of the segments. It is an open question as to which of these two alternatives is best."
okay so if the sender already knows the Path MTU when it sends the initial window (like from a PMTUD cache or some other IETF-approved method), then the sender SHOULD use that MTU for segments in the initial window. 🧚
But the sender doesn't always know the Path MTU when it sends those first packets 💀 so it should be conservative about packet size. Sending a bunch of overly large packets with the DF bit set is not it, but sending a bunch of packets that get fragmented in the network is also a big nope. 🙈
So if the sender doesn't know the Path MTU yet, the sender SHOULD send one large packet in the initial window with the DF bit set, and send the rest of the packets in that window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6). ✨
A second option is to wait one round-trip time before sending the Quick-Start Request. You'd send the request along with the first window of data, and do Path MTU Discovery at the same time. 🦋
The sender might also be using an iterative approach like Packetization Layer Path MTU Discovery (PLPMTUD) [MH06], where it tests successively larger MTUs. If a probe gets delivered successfully, the MTU can be raised to match that probe's value. ngl PLPMTUD can't tell the sender the Path MTU before the initial window goes out, so keep that in mind 💅
4.7.2. Quick-Start Request Packets that are Discarded by Routers or Middleboxes 🌸
so it's always possible for a TCP SYN packet with a Quick-Start request to just get dropped 😭 either because of congestion, or because routers or middleboxes block it. (A middlebox is any intermediary box doing stuff beyond the normal, standard functions of an IP router on the data path between a source host and destination host [RFC3234].)
The measurement studies of middlebox interactions [MAF04] are kinda wild 👀 For 70% of the Web servers they looked at, no connection got established if the TCP SYN packet had an unknown IP option. For 43% of the Web servers, no connection got established if the TCP SYN packet had an IP TimeStamp Option. Both of these are presumably because of routers or middleboxes along the path. Not fair!! 😤
If the TCP sender doesn't get any response to the SYN or SYN/ACK packet carrying the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request. 🫶
Same vibe if the TCP sender gets a TCP reset in response to that SYN or SYN/ACK packet. Then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request [RFC3360]. 💖
RFCs 1122 and 2988 say the sender should set the initial RTO (retransmission timeout) to three seconds, even though lots of TCP implementations use one second instead 🙃 For a TCP SYN packet sent with a Quick-Start request, the TCP sender SHOULD use an initial RTO of three seconds. ⭐
Now here's the messy bit 🌈 If the TCP SYN packet is using the IP Quick-Start Option and uses bits in the TCP header to negotiate ECN-capability with the other end, then a dropped SYN could be because of congestion, or a router or middlebox dropping it because of the IP Option, or a router or middlebox dropping it because of the ECN bits in the TCP header. In that case, the sender could resend the dropped packet with neither the Quick-Start nor the ECN requests. Or, alternately, it could resend with only the ECN request in the TCP header, and then drop both if the second SYN also gets dropped. The second choice seems reasonable, because a TCP SYN today is more likely to be blocked by policies that discard packets with IP Options than by policies that discard packets with ECN requests in the TCP header [MAF04]. 🧠
4.8. TCP: A Quick-Start Request in the Middle of a Connection 🦋
this section covers the stuff that comes up when Quick-Start is used by TCP to ask for a larger window in the middle of a connection, like after an idle period. There are three issues: (1) figuring out the rate to request; (2) when to make a request; and (3) what to do if Quick-Start packets get dropped.
(1) Determining the rate to request:
If a connection hasn't had a congestion event yet (that's a marked or dropped packet), the TCP sender isn't restricted in the rate it can request ✨ For example, a server might wait and send a Quick-Start Request after a short back-and-forth with the client.
To use a Quick-Start Request in a connection that has already had a congestion event, and that hasn't had a recent mobility event, the TCP sender can find the largest congestion window the connection reached since the last packet drop. Then it translates that into a sending rate to get the maximum allowed request rate 💅 If the request is granted, the sender basically restarts with its old congestion window from before it got reduced (for example, during an idle period). Main character energy 👑
A Quick-Start Request sent in the middle of a TCP connection SHOULD be sent on a data packet. 🌸
(2) When to make a request:
A TCP connection MAY make a Quick-Start Request before the connection has had a congestion event, or after an idle period of at least one RTO. 🧚
(3) Response if Quick-Start packets are dropped:
If Quick-Start packets get dropped in the middle of a connection, then the sender MUST revert to half the Quick-Start window, or to the congestion window that the sender would have used if the Quick-Start request had not been approved, whichever is smaller. Periodt 💀💖
4.9. An Example Quick-Start Scenario with TCP 🎀
okay so here's a walkthrough of when both hosts ask for Quick-Start to set their initial windows 🦋 It's similar to Figures 1 and 2 in Section 2.1, except this one shows a TCP connection where both TCP hosts send Quick-Start Requests.
- The TCP SYN packet from Host A carries a Quick-Start Request in the IP header.
- Routers along the forward path modify the Quick-Start Request as appropriate.
- Host B gets the Quick-Start Request in the SYN packet and calculates the TTL Diff. If Host B approves the Quick-Start Request, it sends a Quick-Start Response in the TCP header of the SYN/ACK packet. Host B also sends a Quick-Start Request in the IP header of the SYN/ACK packet.
- Routers along the reverse path modify the Quick-Start Request as appropriate.
- Host A gets the Quick-Start Response in the SYN/ACK packet and checks the TTL Diff, Rate Request, and QS Nonce for validity. If they're valid, Host A sets its initial congestion window appropriately and sets up rate-based pacing to be used with the initial window. If the Quick-Start Response isn't valid, Host A uses TCP's default initial window. Either way, Host A sends a Report of Approved Rate.
Host A also calculates the TTL Diff for the Quick-Start Request in the incoming SYN/ACK packet, and sends a Quick-Start Response in the TCP header of the ACK packet. ✨
- Host B gets the Quick-Start Response in an ACK packet and checks the TTL Diff, Rate Request, and QS Nonce for validity. If the Quick-Start Response is valid, Host B sets its initial congestion window appropriately and sets up rate-based pacing for its initial window. If it isn't valid, Host B uses TCP's default initial window. Either way, Host B sends a Report of Approved Rate. 🫶
5. Quick-Start and IPsec AH 🔐
this section shows that Quick-Start plays nicely with the IPsec Authentication Header (AH) 💅 AH uses an Integrity Check Value (ICV) in the IPsec Authentication Header to verify both message authentication and integrity [RFC4302]. Changes to the Quick-Start Option in the IP header don't affect this AH ICV. The tunnel considerations in Section 6 below apply to all IPsec tunnels, no matter what IPsec headers or processing are used with the tunnel.
Since the contents of the Quick-Start Option can change along the path, it's important that those changes don't mess with the IPsec Authentication Header Integrity Check Value (AH ICV) 🙈 For IPv4, RFC 4302 requires that unrecognized IPv4 options be zeroed for AH ICV computation, so Quick-Start IP Option data changing en route doesn't 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. 🔥
For IPv6, the option numbers explicitly say whether the option is mutable. The third-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 4302 requires that the option data of any such option be zeroed for AH ICV computation purposes. So changes to the Quick-Start Option in the IP header don't affect the calculation of the AH ICV. ✨🌈
6. Quick-Start in IP Tunnels and MPLS ✨
okay bestie, this section is all about tunnels 🚇 and how Quick-Start vibes with them. We're looking at IPsec ([RFC4301]), IP in IP [RFC2003], GRE [RFC2784], and others. We also check how Quick-Start gets along with MPLS [RFC3031] 💜
Quick reminder 🎀: TTL Diff is the difference between the IP TTL and the Quick-Start TTL, mod 256. We defined it earlier! The sender only considers a Quick-Start Request approved if TTL Diff is the same for the packet entering the network as it is for the packet exiting the network. no cap, that's the whole game 😤
Simple tunnels 📦 are based on adding a new "outer" IP header that wraps around the original "inner" IP header and its packet. In lots of cases, that outer header can be added and removed at points along the path, so the network can set up a tunnel without the endpoints having to take part 🧚 We call tunnels that say the outer header gets thrown away at the tunnel egress "simple tunnels" 🍓. We call tunnels where the egress saves and uses info from the outer header before tossing it "non-simple tunnels" 🌈. An example of a non-simple tunnel is one set up to support ECN, where the egress router might copy the ECN codepoint from the outer header into the inner header before dropping the outer header [RFC3168]. ✨
__ Tunnels Compatible with Quick-Start
/
Simple Tunnels __/
\
\__ Tunnels Not Compatible with Quick-Start
(False Positives!)
__ Tunnels Supporting Quick-Start
/
/
Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start,
\ but Not Supporting Quick-Start
\
\__ Tunnels Not Compatible with Quick-Start?Figure 6: Categories of Tunnels. 🦋
Tunnels that are compatible with Quick-Start 🫶: we say an IP tunnel is not compatible with Quick-Start if using a Quick-Start Request over it allows false positives. That's when the TCP sender wrongly thinks every router on the path approved the request 😭. If using Quick-Start over the tunnel doesn't cause false positives, then the IP tunnel is compatible with Quick-Start 💅
If the IP TTL of the inner header gets decremented during forwarding before the tunnel encapsulation happens, then the simple tunnel is compatible with Quick-Start, with Quick-Start Requests getting rejected. Section 6.1 breaks down the ways a simple tunnel can be compatible with Quick-Start 💖
Some simple tunnels are not compatible with Quick-Start, though, and they allow false positives where the TCP sender wrongly believes the Quick-Start Request was approved by all routers along the path 🙈 This is covered in Section 6.2 below.
One thing on our future to-do list 📝 is to look into how often tunnels that are not compatible with Quick-Start show up, and to keep track of how much those tunnels change over time. How we evaluate the false positive problem from these tunnels will shape whether Quick-Start moves from Experimental to Proposed Standard, and how widely it gets deployed while it's still Experimental 👑
Tunnels that support Quick-Start 🧚: we say an IP tunnel supports Quick-Start if it lets routers along the tunnel path process the Quick-Start Request and give feedback, which can lead to the request being accepted when it should be. Some tunnels that are compatible with Quick-Start also support it, and others don't. Just so you know, a simple tunnel can't support Quick-Start 🙅♀️
Security check 🔐 (this part is serious, bestie!): using Quick-Start in the outer header of an IP tunnel might raise security concerns. An adversary could tamper with the Quick-Start information that carries on past the tunnel endpoint, and the Quick-Start Option exposes information to network scanners too 😱 So our approach is to make supporting Quick-Start an option for IP tunnels. In environments or tunneling protocols where the risks of using Quick-Start seem bigger than the benefits, the tunnel can just delete the Quick-Start Option, or zero the Quick-Start rate request and QS TTL fields, before encapsulation 🛡️ That leaves two viable options for IP tunnels to be compatible with Quick-Start. The first is the simple tunnel described above and in Section 6.1, where the tunnel is compatible with Quick-Start but doesn't support it, so every Quick-Start Request along the path gets rejected. The second is a Quick-Start-capable mode, described in Section 6.3, where the tunnel actively supports Quick-Start 💜
6.1. Simple Tunnels that Are Compatible with Quick-Start 🎀
This section describes the ways a simple tunnel can be compatible with Quick-Start but not support it, which means every Quick-Start Request that goes through the tunnel gets rejected 🙃
If the tunnel ingress for the simple tunnel is at a router, the IP TTL of the inner header is usually decremented during forwarding before tunnel encapsulation happens. In that case TTL Diff changes, and the Quick-Start Request gets rejected like it should 💅 For a simple tunnel, it's better if the Quick-Start Request isn't copied to the outer header, so the routers inside the tunnel don't waste time processing a Quick-Start Request for no reason 🧹 Even so, the Quick-Start Request is still rejected correctly whether or not it gets copied to the outer header ✨
6.1.1. Simple Tunnels that Are Aware of Quick-Start 🧠
If a tunnel ingress knows about Quick-Start but doesn't want to support it, then the tunnel ingress MUST either zero the Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the Quick-Start Option from the inner header before encapsulation. Section 6.3 explains the procedures for a tunnel that does want to support Quick-Start 🦋
Deleting the Quick-Start Option, or zeroing the Quick-Start rate request after decapsulation, also stops Quick-Start information from spreading, and it's compatible with Quick-Start 🫶 If the outer header doesn't contain a Quick-Start Request, a Quick-Start-aware tunnel egress MUST reject the inner Quick-Start Request, either by zeroing the Rate Request field in the inner header or by deleting the Quick-Start Option 🚫
If the tunnel ingress is at a sending host or router where the IP TTL isn't decremented before encapsulation, and neither tunnel endpoint knows about Quick-Start, then false positives become possible. That's described in the section below 👀
6.2. Simple Tunnels that Are Not Compatible with Quick-Start 😬
Sometimes a tunnel implementation that doesn't support Quick-Start is independent of the TCP sender or the router implementation that does support it. In these cases, a Quick-Start Request can get approved by mistake even though the routers in the tunnel never individually approved it. That's a false positive 🙈
If a tunnel ingress is a separate component from the TCP sender or the IP forwarding, a packet with a Quick-Start option might get encapsulated without its IP TTL being decremented first, or with both IP TTL and QS TTL decremented before the tunnel encapsulation happens. If the tunnel ingress doesn't know about Quick-Start, a valid Quick-Start Request with an unchanged TTL Diff travels in the inner header, while the outer header most likely doesn't carry a Quick-Start Request. If the tunnel egress also doesn't support Quick-Start, the Quick-Start Request could still get falsely approved, because the packet is decapsulated using the Quick-Start Request from the inner header, and the TTL Diff value echoed back to the sender stays the same 😱 For example, this can happen with a Bump-In-The-Stack (BITS), an IPsec encryption implementation where the data encryption happens between the network drivers and the TCP/IP protocol stack [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 🙈 That's a big 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'll dig into this in more detail 🔍
A Bump-In-The-Wire (BITW) is an IPsec encryption implementation where the encryption happens on an outboard processor, which takes the encryption overhead off the host or router [RFC4301] 🧚 The BITW device is usually IP addressable, which means the IP TTL gets decremented before the packet is passed to the BITW. If the QS TTL isn't decremented, then the value of TTL Diff changes, and the Quick-Start Request gets denied 🙅♀️ However, if the BITW supports a host and doesn't have its own IP address, then the IP TTL isn't decremented before the packet goes from the host to the BITW, and a false positive could happen 😭
Other tunnels to look at are IP tunnels over non-network protocols, like IP over TCP and IP over UDP [RFC3948], and tunnels using the Layer Two Tunneling Protocol [RFC2661] 🌸
Section 9.2 discusses the related issue of non-IP queues, such as layer-two Ethernet or ATM (Asynchronous Transfer Mode) networks, as another kind of possible bottleneck that doesn't take part in the Quick-Start feedback 🫧
6.3. Tunnels That Support Quick-Start ✨
okay so this bit is all about tunnels that are set up to support Quick-Start 🎀
If the tunnel ingress node chooses to locally approve the Quick-Start Request, then the ingress node MUST decrement the Quick-Start TTL at the same time it decrements the IP TTL, and MUST copy IP TTL and the Quick-Start Option from the inner IP header to the outer header. During encapsulation, the tunnel ingress MUST zero the Quick-Start rate request field in the inner header to ensure that the Quick-Start Request will be rejected if the tunnel egress does not support Quick-Start 💅
If the tunnel ingress node does not choose to locally approve the Quick-Start Request, then it MUST either delete the Quick-Start option from the inner header before encapsulation, or zero the QS TTL and the Rate Request fields before encapsulation 🙈
Upon decapsulation, if the outer header contains a Quick-Start option, the tunnel egress MUST copy the IP TTL and the Quick-Start option from the outer IP header to the inner header. bestie, that's the main rule for the way back out 🦋
IPsec uses the IKE (Internet Key Exchange) Protocol for security associations. We do not consider the interactions between Quick-Start and IPsec with IKEv1 [RFC2409] in this document. Now that the RFC for IKEv2 [RFC4306] is published, we plan to specify a modification of IPsec to allow the support of Quick-Start to be negotiated; this modification will specify the negotiation between tunnel endpoints to allow or forbid support for Quick-Start within the tunnel. This was done for ECN for IPsec tunnels, with IKEv1 [RFC3168, Section 9.2]. This negotiation of Quick-Start capability in an IPsec tunnel will be specified in a separate IPsec document. This document will also include a discussion of the potential effects of an adversary's modifications of the Quick-Start field (as in Sections 18 and 19 of RFC 3168), and of the security considerations of exposing the Quick-Start rate request to network scanners. the security vibes here are very serious 😭🔥
6.4. Quick-Start and MPLS 🧚
The behavior of Quick-Start with MPLS is similar to the behavior of Quick-Start with IP Tunnels. For those MPLS paths where the IP TTL is decremented as part of traversing the MPLS path, these paths are compatible with Quick-Start, but do not support Quick-Start; Quick-Start Requests that are traversing these paths will be correctly understood by the transport sender as having been denied. Any MPLS paths where the IP TTL is not decremented as part of traversing the MPLS path would be not compatible with Quick-Start; such paths would result in false positives, where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path. not the vibe, so watch out for those paths 💀
For cases where the ingress node to the MPLS path is aware of Quick-Start, this node should either zero the Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the Quick-Start Option from the IP header. ✨
7. The Quick-Start Mechanism in Other Transport Protocols 🌈
The section earlier specified the use of Quick-Start in TCP. In this section, we generalize this to give guidelines for the use of Quick-Start with other transport protocols. We also discuss briefly how Quick-Start could be specified for other transport protocols. so we're taking the TCP rules and making them work for everyone else 👑
The general guidelines for Quick-Start in transport protocols are as follows:
- Quick-Start is only specified for unicast transport protocols with appropriate congestion control mechanisms. Note: Quick-Start is not a replacement for standard congestion control techniques, but meant to augment their operation. the main point is it's a boost, not a replacement 🫶
- A transport-level mechanism is needed for the Quick-Start Response from the receiver to the sender. This response contains the Rate Request, TTL Diff, and QS Nonce.
- The sender checks the validity of the Quick-Start Response.
- The sender has an estimate of the round-trip time, and translates the Quick-Start Response into an allowed window or allowed sending rate. The sender sends a Report of the Approved Rate. The sender starts sending Quick-Start packets, rate-paced out at the approved sending rate.
- After the sender receives the first acknowledgement packet for a Quick-Start packet, no more Quick-Start packets are sent. The sender adjusts its current congestion window or sending rate to be consistent with the actual amount of data that was transmitted in that round-trip time.
- When the last Quick-Start packet is acknowledged, the sender continues using the standard congestion control mechanisms of that protocol.
- If one of the Quick-Start packets is lost, then the sender reverts to the standard congestion control method of that protocol that would have been used if the Quick-Start Request had not been approved. In addition, the sender takes into account the information that the Quick-Start congestion window was too large (e.g., by decreasing
ssthreshin TCP). oof, loss means the sender has to play it safe 😭
8. Using Quick-Start 🎀
8.1. Determining the Rate to Request 🍓
As discussed in [SAF06], the data sender does not necessarily have information about the size of the data transfer at connection initiation; for example, in request-response protocols such as HTTP, the server doesn't know the size or name of the requested object during connection initiation. [SAF06] explores some of the performance implications of overly large Quick-Start Requests, and discusses heuristics that end-nodes could use to size their requests appropriately. For example, the sender might have information about the bandwidth of the last-mile hop, the size of the local socket buffer, or of the TCP receive window, and could use this information in determining the rate to request. Web servers that mostly have small objects to transfer might decide not to use Quick-Start at all, since Quick-Start would be of little benefit to them. small objects don't need the extra boost, so skipping it is totally fine 🌸
Quick-Start will be more effective if Quick-Start Requests are not larger than necessary; every Quick-Start Request that is approved but not used (or not fully used) takes away from the bandwidth pool available for granting successive Quick-Start Requests. so don't over-ask, because unused approvals are a waste for everyone 💜
8.2. Deciding the Permitted Rate Request at a Router 🦋
In this section, we briefly outline how a router might decide whether or not to approve a Quick-Start Request. The router should ask the following questions:
- Has the router's output link been underutilized for some time (e.g., several seconds)?
- Would the output link remain underutilized if the arrival rate were to increase by the aggregate rate requests that the router has approved over the last fraction of a second?
In order to answer the last question, the router must have some knowledge of the available bandwidth on the output link and of the Quick-Start bandwidth that could arrive due to recently approved Quick-Start Requests. In this way, if an underutilized router experiences a flood of Quick-Start Requests, the router can begin to deny Quick-Start Requests while the output link is still underutilized. the router is basically the bouncer here 💅
A simple way for the router to keep track of the potential bandwidth from recently approved requests is to maintain two counters: one for the total aggregate Rate Requests that have been approved in the current time interval [T1, T2], and one for the total aggregate Rate Requests approved over a previous time interval [T0, T1]. However, this document doesn't specify router algorithms for approving Quick-Start Requests, or make requirements for the appropriate time intervals for remembering the aggregate approved Quick-Start bandwidth. A possible router algorithm is given in Appendix E, and more discussion of these issues is available in [SAF06].
- If the router's output link has been underutilized and the aggregate of the Quick-Start Request Rate options granted is low enough to prevent a near-term bandwidth shortage, then the router could approve the Quick-Start Request.
Section 10.2 discusses some of the implementation issues in processing Quick-Start Requests at routers. [SAF06] discusses the range of possible Quick-Start algorithms at the router for deciding whether to approve a Quick-Start Request. In order to explore the limits of the possible functionality at routers, [SAF06] also discusses Extreme Quick-Start mechanisms at routers, where the router would keep per-flow state concerning approved Quick-Start requests. the "extreme" version is basically the router keeping notes on every single flow 👑
9. Evaluation of Quick-Start ✨
9.1. Benefits of Quick-Start 🌈
The main benefit of Quick-Start is the faster start-up for the transport connection itself. For a small TCP transfer of one to five packets, Quick-Start is probably of very little benefit; at best, it might shorten the connection lifetime from three to two round-trip times (including the round-trip time for connection establishment). Similarly, for a very large transfer, where the slow-start phase would have been only a small fraction of the connection lifetime, Quick-Start would be of limited benefit. Quick-Start would not significantly shorten the connection lifetime, but it might eliminate or at least shorten the start-up phase. However, for moderate-sized connections in a well-provisioned environment, Quick-Start could possibly allow the entire transfer of M packets to be completed in one round-trip time (after the initial round-trip time for the SYN exchange), instead of the log_2(M)-2 round-trip times that it would normally take for the data transfer, in an uncongested environments (assuming an initial window of four packets). this is the part where it really shines, slay 🚀💖
9.2. Costs of Quick-Start 💅
okay so this section is about what Quick-Start actually costs the connection and the routers along the path 👀 nothing is free bestie 😭
The cost of having a Quick-Start Request packet dropped: measurement studies cited earlier [MAF04] suggest that on a wide range of paths on the Internet, TCP SYN packets with unknown IP options get dropped 💀 so the sender's risk is that the packet carrying the Quick-Start Request never makes it through the network. this one hurts extra because if a TCP SYN gets dropped, the sender has to wait for an RTO of three seconds before resending the SYN, as specified in Section 4.7.2. three whole seconds just sitting there 🥲
The cost of having a Quick-Start data packet dropped: the other risk is getting hit by congestion-related losses on the Quick-Start data packets 😬 this should be pretty unlikely, since routers are only expected to approve Quick-Start Requests when they're significantly underutilized 🌸 BUT a sudden burst of cross-traffic at one router, a link's available bandwidth dropping out from under you, or congestion at a non-IP queue could still cause packet losses even when every router on the path approved the request. if a Quick-Start packet gets dropped, the sender falls back to the congestion control mechanisms it would have used if the Quick-Start Request hadn't been approved at all. so the performance cost of one dropped Quick-Start packet is small compared to running without Quick-Start at all ✨ (on the other hand, the gap between Quick-Start with a dropped packet and Quick-Start with no dropped packets can be considerable 🙈)
Added complexity at routers: the big cost of Quick-Start lives at the routers, mostly in complexity 🧠 the added complexity at the end-points is moderate, and it could easily be outweighed by the benefit Quick-Start gives the end hosts 💖 the added complexity at the routers is also somewhat moderate. they have to estimate the unused bandwidth on the output link over the last several seconds, process the Quick-Start request, and keep a counter of the aggregate Quick-Start rate approved over the last fraction of a second. BUT (lowkey the most important part) this extra work adds to the development cycle and could block other competing functionality from getting added to routers 😤 so careful thought would have to go into adding Quick-Start to IP. no rushing!! 🎀
The slow path in routers: another drawback is that packets carrying the Quick-Start Request message might not take the fast path in routers, especially early on while Quick-Start is still getting deployed on the Internet 🐢 that means extra delay for the end hosts and extra processing burden for the routers. however, as discussed in Sections 4.1 and 4.7, not every packet carries the Quick-Start option, so that helps 🙌 also, on the underutilized links where Quick-Start Requests could actually get approved, or in typical environments where most packets belong to large flows, the burden of the Quick-Start Option on routers would be considerably reduced. still, in the worst case it's totally conceivable that a lot of packets would carry Quick-Start Requests, and that could slow down the processing of Quick-Start packets in routers quite a bit 💀 as discussed in Section 9.6, routers can easily protect against this by enforcing a limit on the rate at which Quick-Start Requests will be considered. [RW03] and [RW04] contain measurements of the impact of IP Option Processing on packet round-trip times, if you want to get into the receipts 🤓
Multiple paths: one limitation of Quick-Start is that it assumes the data packets of a connection follow the same path as the Quick-Start request packet 🛤️ if that's not the case, the connection could be sending Quick-Start packets at the approved rate down a path that was already congested, or one that became congested because of this very connection. so Quick-Start could give poor performance when there's a routing change right after the Quick-Start Request gets approved, and the Quick-Start data packets take a different path than the original request did 😵💫 this is, however, similar to what happens for a connection with enough data if its path changes in the middle of the connection, after it has already established the allowed initial rate.
As specified in Section 3.3, a router that uses multipath routing for packets within a single connection must not approve a Quick-Start Request. Quick-Start just wouldn't perform robustly where multipath routing is happening and different packets in one connection routinely take different paths 🌀 in that kind of environment, the Quick-Start Request and some fraction of the connection's packets might take an underutilized path, while the rest take an alternate, congested one. chaotic behavior, no thank you 🙅♀️
Non-IP queues: a problem with any feedback mechanism from routers at the IP level is that there can be queues and bottlenecks in the end-to-end path that aren't in IP-level routers 🫠 examples include queues in layer-two Ethernet or ATM networks. one possibility is that an IP-level router sitting next to one of these non-IP queues or bottlenecks would be configured to reject Quick-Start Requests if that was appropriate 🙏 in general, the hope is that IP networks are configured so non-IP queues between IP routers don't end up being the congested bottlenecks. fingers crossed fr 🤞
9.3. Quick-Start with QoS-Enabled Traffic 🎀
so far we've mostly been talking about Quick-Start with default, best-effort traffic 🌷 BUT Quick-Start could also be used by traffic that uses some form of differentiated services, and routers could take the traffic class into account when deciding whether or not to grant the Quick-Start Request ✨ we're not going to dig into this context any further in this paper, since it's orthogonal to the specification of Quick-Start, so no stress 🫶
Routers are also free to take their own priority classifications into account when processing Quick-Start Requests 💜
9.4. Protection against Misbehaving Nodes 🕵️♀️
this section is all about protecting against senders, receivers, or colluding routers or middleboxes that might be lying about the Quick-Start Request 👀 cheaters get the spotlight here, babe 💅
9.4.1. Misbehaving Senders
okay so a transport sender could try to send data at a higher rate than the one approved in the Quick-Start Request 😤 the network could use a traffic policer to protect against misbehaving senders that go over the approved rate, for example by dropping packets that exceed the allowed transmission rate 🚨 the required Report of Approved Rate lets traffic policers check that the Report of Approved Rate doesn't exceed the Rate Request actually approved at that point in the network in the previous Quick-Start Request from that connection. the required Approved Rate report also lets traffic policers check that the sender's sending rate doesn't exceed the rate in the Report of Approved Rate 📊 so the receipts are checkable from both ends 🧾
If a router or receiver gets an Approved Rate report that's larger than the Rate Request in the Quick-Start Request that was approved for that sender and that connection in the previous round-trip time, then the router or receiver could deny future Quick-Start Requests from that sender, e.g., by deleting the Quick-Start Request from future packets from that sender 🚫 we should note that routers are not required to use Approved Rate reports to check whether senders are cheating. that's at the discretion of the router 🫡
If a router sees a Report of Approved Rate but didn't see an earlier Quick-Start Request, then either the sender could be cheating, or the connection's path could have changed since the Quick-Start Request was sent 🤔 either way, the router could decide to deny future Quick-Start Requests for this connection. in particular, it's reasonable for the router to deny a Quick-Start request if either the sender is cheating, or if the connection path suffers from path changes or multipathing 🙅♀️
If a router approved a Quick-Start Request but doesn't see a subsequent Approved Rate report, then there are several possibilities. (1) the request was denied and/or dropped downstream, and the sender didn't send a Report of Approved Rate; (2) the request was approved, but the sender didn't send a Report of Approved Rate; (3) the Approved Rate report was dropped in the network; or (4) the Approved Rate report took a different path from the Quick-Start Request 🧩 in any of these cases, the router would be justified in denying future Quick-Start Requests for this connection 💀
In any of the cases mentioned in the three paragraphs above (i.e., an Approved Rate report that's larger than the Rate Request in the earlier Quick-Start Request, a Report of Approved Rate with no preceding Rate Request, or a Rate Request with no Report of Approved Rate), a traffic policer may assume that Quick-Start isn't being used appropriately, or is being used in an unsuitable environment (e.g., with multiple paths), and take some corresponding action 🚓 basically if the receipts don't match up, the policer is allowed to side-eye 👀
What are the incentives for a sender to cheat by over-sending after a Quick-Start Request? 🤨 assuming the sender's interests are measured by a performance metric such as the completion time for its connections, sometimes it might be in the sender's interests to cheat, and sometimes it might not. in some cases it could be hard for the sender to judge whether cheating would actually be in its interests 😵 the incentives to over-send after a Quick-Start Request aren't that different from the incentives to over-send even without Quick-Start, with one difference: Quick-Start could help a sender evade policing actions from policers in the network 👻 the Report of Approved Rate is designed to address this and to make it harder for senders to use Quick-Start to 'cover' their cheating 🫵🔥
9.4.2. Receivers Lying about Whether the Request was Approved
okay so bestie, this is the part where somebody on the receiving end tries to be sneaky 🙈 Lying about whether a Quick-Start Request got approved would mean faking the TTL Diff and QS Nonce values. If a router that understands the request says no by deleting it or zeroing the QS TTL and QS Nonce, the receiver can only "lie" by guessing those values correctly. The odds of guessing the TTL Diff are 1/256 💀, and the odds of guessing the QS Nonce for a reported rate request of K are 1/(2K). Not a lot of wins there, ngl ✨
However, if the request is only denied by a router that isn't Quick-Start-capable, or by a router that can't zero the QS TTL and QS Nonce fields, then the receiver could cheat by changing the QS TTL in successive requests from the same host 🎀. Like, if the sender doesn't act on a Quick-Start Request, the receiver could decrement the QS TTL by one in the next request before calculating the TTL Diff, then by two in the one after that, and keep going until the sender finally acts on one of them. Iconic villain behaviour, honestly 😭
Here's the tea 🫖: if a router doesn't understand Quick-Start, it can't actively zero the QS TTL and QS Nonce to deny anything. So the QS TTL is not a fail-safe for stopping receivers from lying when non-Quick-Start-capable routers are involved 🦋
So what would make a receiver want to cheat without something like the QS Nonce? Sometimes cheating is seriously beneficial for them, because the transfer finishes faster 🚀 In other cases, cheating would make Quick-Start packets get dropped in the network, and then it might or might not help their performance metric. It totally depends on the scenario 🤷♀️
9.4.3. Receivers Lying about the Approved Rate
A second kind of receiver misbehaviour is lying to the sender about the Rate Request for an approved Quick-Start Request by bumping up the value of the Rate Request field 💅. But the receiver doesn't necessarily know what Rate Request the sender originally sent, and the sender will only accept a higher Rate Request if it's no higher than the one it originally asked for ✨. So say the sender sends a Quick-Start Request with a Rate Request of X, and the receiver says it got one with a Rate Request of Y > X. The sender then knows either some router on the path messed up and increased the Rate Request by mistake, or the receiver is fibbing about what was in the packet 👀
If the sender sends a Rate Request of Z, the receiver gets an approved Rate Request of X, and reports a Rate Request of Y, where X < Y <= Z, then the receiver only gets away with lying about the approved rate if they manage to report the rightmost 2Y bits of the QS nonce 🧚
Also, if senders often use a configured default value for the Rate Request, receivers could just guess the original value, which makes lying way easier 🙃 Similarly, if a receiver often talks to one particular sender, and that sender always uses the same Rate Request for it, the receiver might eventually figure out the original Rate Request over time 🕵️♀️
There are a few possible extra protections against receivers lying about the Rate Request 🛡️ One idea is for a router that lowers a Rate Request in a Quick-Start Request to report the decrease straight back to the sender. The catch is that this could mean lots of reports for a single request, and it could also be abused in address-spoofing attacks 😬
A second, more limited protection is for senders to randomise the requested Rate Request a bit, so receivers can't easily guess the original value. But that's tricky, because the rate requests a sender can pick are pretty coarsely spaced, and randomising the initial request only helps a little bit anyway 🌸
9.4.4. Collusion between Misbehaving Routers
Okay, so we also have to protect against routers that misbehave, not just receivers 🫣 Picture an ingress router and an egress router in the same intranet working together. The ingress router could lower the Rate Request at the ingress, and then the egress router bumps it back up at the egress 💀. The routers in between that approved the lowered request might not have said yes to the bigger original one 😤
Another sneaky move is for the ingress router to tell the egress router, out-of-band, what the TTL Diff and QS Nonce were for the request packet at the ingress 🕶️. That lets the egress router change the QS TTL and QS Nonce so it looks like every router along the path approved the request 🎭. There doesn't seem to be any protection against a colluding ingress and egress pair. Even if an intermediate router deleted the Quick-Start Option from the packet, the ingress router could send the Quick-Start Option to the egress router out-of-band, and the egress router could insert it back into the packet with a modified QS TTL field 🪄
Here's the twist, though 🌈: unlike ECN, cooperating ingress and egress routers have less of a reason to collude to fake an approval. With ECN, a colluding ingress router could falsely mark a packet as ECN-capable, the egress router could change the IP header's ECN field back to the original non-ECN-capable codepoint, and congested routers might be tricked into not dropping that packet. That would give the protected traffic an unfair advantage 😤
With Quick-Start, though, faking an approval might help the covered traffic sometimes and hurt it other times, depending on the scenario 🎢. If some router on the path really doesn't have enough bandwidth to approve the request, the Quick-Start packets sent because of the fake approval could get dropped in the network, which could hurt the connection 😬. So even though the ingress and egress routers could collude to stop intermediate routers from denying a request, it wouldn't always be good for the connection 🙅♀️. One defence would be for a router between the ingress and egress that denied the request to keep an eye on connection performance, and penalise connections that seem to be using Quick-Start after their request was denied, or that report an Approved Rate higher than the one that router actually approved 👑
If the congested router is ECN-capable, and the colluding ingress and egress routers are lying about ECN-capability as well as Quick-Start, then the Quick-Start Request could falsely look approved to the sender, and the Quick-Start packets could falsely look ECN-capable to the congested router 🥺. In that case, the colluding routers might actually manage to give a competitive advantage to the traffic they protect, if no intermediate router is watching for this misbehaviour 🦹♀️
9.5. Misbehaving Middleboxes and the IP TTL
One possible problem is traffic normalizers [HKP01], or other middleboxes along the path, that rewrite IP TTLs to foil other kinds of attacks in the network 🧱. If a traffic normalizer rewrote the IP TTL but didn't adjust the Quick-Start TTL by the same amount, the sender's way of figuring out whether the request was approved by every router on the path wouldn't be reliable anymore 😵💫. Rewriting the IP TTL could cause false positives (where the sender wrongly thinks the Quick-Start Request was approved) and also false negatives (where the sender wrongly thinks it was denied) 🌀
9.6. Attacks on Quick-Start
As discussed in [SAF06], Quick-Start is vulnerable to two kinds of attacks 🚨: (1) attacks that increase the routers' processing and state load, and (2) attacks with bogus Quick-Start Requests that temporarily tie up the available Quick-Start bandwidth, stopping routers from approving Quick-Start Requests from other connections. Routers can guard against the first kind by putting a simple limit on the rate at which they'll consider Quick-Start Requests 🛑
The second kind, tying up the available Quick-Start bandwidth, is harder to defend against 😩. As discussed in [SAF06], Quick-Start Requests that never get used, either because they come from malicious attackers or because routers downstream deny them, can cause short-term "wasting" of potential Quick-Start bandwidth 🗑️. That can make routers deny later Quick-Start Requests that would actually have been used if they'd been approved 💔
We should note that malicious attacks are much less likely when Quick-Start is deployed in a controlled environment like an intranet, where there's some form of centralised control over the users in the system 🏢. We also note that this kind of attack could make Quick-Start unusable, but it wouldn't do any further damage. In the worst case, the network would just work like a network without Quick-Start 🫶
[SAF06] looks at the potential of Extreme Quick-Start algorithms at routers, which keep per-flow state for Quick-Start connections, to protect the availability of Quick-Start bandwidth when there are frequent, overly large Quick-Start Requests 🦋
9.7. Simulations with Quick-Start 🧪
Okay so Quick-Start got added to the NS simulator [SH02] by Srikanth Sundarrajan, and then Pasi Sarolahti added even more functionality 💖 The validation test lives at test-all-quickstart' in the tcl/test' directory in NS, so you can check it yourself, bestie ✨
The early simulation studies in [SH02] showed a significant performance improvement for moderate-sized flows (between 4 KB and 128 KB) in underutilized environments 🦋 These studies looked at file transfers, and the improvement was measured as the relative increase in overall throughput for the file transfer. The big takeaway is that the potential improvement from Quick-Start is proportional to the delay-bandwidth product of the path. So the bigger the pipe, the more it slaps 🔥
The Quick-Start simulations in [SAF06] explore a few things: the potential benefit of Quick-Start for the connection, the relative benefits of different router-based algorithms for approving Quick-Start Requests, and how effective Quick-Start is depending on the senders' algorithms for choosing the size of the rate request 🎀
10. Implementation and Deployment Issues 🛠️
This section is where we talk about the implementation issues with Quick-Start 💅 It also covers some of the key deployment issues, like the chicken-and-egg problem 🥚 Mechanisms that have to be deployed in both routers and end nodes in order to work are kind of stuck waiting on each other, and then there's the problem of wide middlebox deployment today, which blocks the use of known or unknown IP Options 😭
10.1. Implementation Issues for Sending Quick-Start Requests 📤
Section 4.7 already talks about some of the issues with deciding the initial sending rate to request 🍓 Quick-Start adds extra issues on top of that, about the communication between the transport protocol and the application, and about using past history with Quick-Start in the end node 🧚
One possibility is that a protocol implementation could provide an API so applications can indicate when they want to request Quick-Start, and what rate they'd like to request 💜 In the conventional socket API, this could be a socket option that gets set before a connection is established. Some applications, like ones that use TCP for bulk transfers, don't really care about the transmission rate, but they might know how much data can be sent immediately 👀 Based on that, the sender implementation could decide whether Quick-Start would be useful, and what rate should be requested.
We note that when Quick-Start is used, the TCP sender is required to save the QS Nonce and the TTL Diff when the Quick-Start Request is sent. It also has to implement an additional timer for the paced transmission of Quick-Start packets ⏰
10.2. Implementation Issues for Processing Quick-Start Requests 🧠
A router or other network host must be able to determine the approximate bandwidth of its outbound network interfaces in order to process incoming Quick-Start rate requests, including the ones that come from the host itself 🖥️ One possibility is for hosts to rely on configuration information to figure out link bandwidths. Ngl, this has the drawback of not being robust to configuration errors 🙈 Another possibility is for network device drivers to infer the bandwidth for the interface and tell the IP layer about it.
Particular issues come up for wireless links with variable bandwidth, where decisions have to be made about how often the host gets updates on the changing bandwidth 📶 It seems appropriate to handle Quick-Start Requests particularly conservatively for links with variable bandwidth. The reason is to avoid cases where Quick-Start Requests get approved, the link bandwidth drops, and the data packets that were sent end up getting dropped 😬
Difficult issues also show up for paths with multi-access links, like Ethernet 🧵 Routers or end-nodes with multi-access links should be particularly conservative in granting Quick-Start Requests. For some multi-access links, there may be no procedure an attached node can use to check whether all parts of the multi-access link have been underutilized in the recent past. Major mystery energy 🕵️♀️
10.3. Possible Deployment Scenarios 🌈
Because of the possible problems we just covered about using Quick-Start over some network paths, plus the security issues in Section 11, the most realistic first deployment of Quick-Start would most likely happen in intranets and other controlled environments 🏢 Quick-Start is most useful on high bandwidth-delay paths that are significantly underutilized. The primary early users would likely be organizations that provide network services to their users and also control a large portion of the network path 👑
Quick-Start is not currently intended for ubiquitous deployment in the global Internet 🌍 In particular, Quick-Start should not be enabled by default in end-nodes or in routers. Instead, when Quick-Start is used, it should be explicitly enabled by users or system administrators ✋
Here are a few networking environments where Quick-Start would potentially be useful. These are the places that might consider an initial deployment of Quick-Start in the routers and end-nodes, where the incentives for routers to deploy Quick-Start might be the clearest 💅
- Centrally administrated organizational intranets: These intranets often have large network capacity, and the networks are underutilized for much of the time [PABL+05] 🏫 Such intranets might also include high-bandwidth and high-delay paths to remote sites. In an environment like this, Quick-Start would benefit users, and there would be a clear incentive to deploy Quick-Start in routers. For example, Quick-Start could be super useful in high-bandwidth networks used for scientific computing 🔬
- Wireless networks: Quick-Start could also be useful in high-delay environments of Cellular Wide-Area Wireless Networks, like GPRS [BW97] and its enhancements and next generations 📱 For example, GPRS EDGE (Enhanced Data for GSM Evolution) is expected to provide wireless bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per second). Meanwhile, GPRS round-trip times typically range from a few hundred milliseconds to over a second, not counting any possible queueing delays in the network [GPAR02] 🐢 These networks also sometimes have variable additional delays from resource allocation, which could be avoided by keeping the connection path constantly utilized, starting from initial slow-start. So Quick-Start could be a serious win for users in these environments 🏆
- Paths over satellite links: Geostationary Orbit (GEO) satellite links have one-way propagation delays on the order of 250 ms, while the bandwidth can be measured in megabits per second [RFC2488] 🛰️ Because the bandwidth-delay product on the link is considerable, TCP's slow-start is a major performance limitation at the beginning of the connection. A large initial congestion window would be useful to users of these satellite links 🌟
- Single-hop paths: Quick-Start should work well over point-to-point single-hop paths, like from a host to an adjacent server 🤝 Quick-Start would work over a single-hop IP path consisting of a multi-access link only if the host was able to determine that the path to the next IP hop has been significantly underutilized over the recent past. If the multi-access link includes a layer-2 switch, the attached host can't necessarily determine the status of the other links in the layer-2 network 🙃
10.4. A Comparison with the Deployment Problems of ECN ⚖️
Given the glacially slow rate of ECN deployment in the Internet to date [MAF05], it's kind of disturbing that some of the deployment problems of Quick-Start are even bigger than those of ECN 😭 First, unlike ECN, which can help even if it's only deployed on one of the routers along the end-to-end path, a connection's use of Quick-Start requires Quick-Start deployment on all of the routers along the end-to-end path. Second, unlike ECN, which uses an allocated field in the IP header, Quick-Start needs the extra complications of an IP Option, which can be difficult to pass through the current Internet [MAF05] 🚧
However, despite all that, there's some hope for Quick-Start, at least in protected corners of the Internet 🦋 The potential benefits to the user are way more dramatic than those of ECN. Rather than just replacing the occasional dropped packet with an ECN-marked packet, Quick-Start can dramatically increase the throughput of connections in underutilized environments [SAF06] 🚀✨
11. Security Considerations 🔐
Okay bestie, security is serious business, but Quick-Start's security tea is still juicy 🫖. The main drama lives in Sections 9.4 and 9.6. Section 9.4 covers the shady stuff: senders or receivers lying about whether a request got approved or about the approved rate, and routers teaming up to misuse Quick-Start 🕵️♀️. Section 9.5 is about traffic normalizers that rewrite IP TTLs in packet headers, which can cause problems too.
So here's the thing 😭. All of these could lead to a sender using a Rate Request that's way too big, or a sender thinking its request was approved when at least one router on the path actually denied it. That kind of misuse could cause congestion and an unacceptable level of packet drops along the path. And that congestion could even be part of a Denial of Service attack 💀.
Section 9.6 talks about a potential attack on the routers' processing and state load from a flood of Quick-Start Requests. It also covers an attack on the available Quick-Start bandwidth, where someone sends bogus Quick-Start Requests for bandwidth that never actually gets used 🙈. Does this hurt the global usability of Quick-Start? Yes. But it doesn't endanger the network as a whole, because TCP falls back to standard congestion control when Quick-Start isn't available 🫶.
Section 4.7.2 looks at the possible problem of packets carrying Quick-Start Requests getting 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, so it's completely zeroed for AH ICV calculation purposes ✨. That's also the treatment RFC 4302 requires for unrecognized IPv4 options. The IPv6 Quick-Start Option's IANA-allocated option type says it's a mutable option, so according to RFC 4302, its option data is required to be zeroed for AH ICV computation purposes. Check RFC 4302 for the full explanation 🎀.
Section 6.2 discusses possible problems when Quick-Start is used by connections carried over simple tunnels that aren't compatible with Quick-Start. In that case, a Quick-Start Request might be wrongly considered approved by the sender even though the routers in the tunnel never individually approved it. That's a false positive, and it's giving chaos 🌀.
Two high-order points here, and they're iconic 👑. First, the Quick-Start Nonce goes a long way towards preventing large-scale cheating 🔥. Second, even if a host occasionally uses Quick-Start when the entire network path hasn't approved it, the network won't collapse 🌈. Quick-Start doesn't remove TCP's basic congestion control mechanisms. Those kick in when the network is heavily loaded, which means any Quick-Start mistake is just a transient blip 🦋.
12. IANA Considerations 📋
Quick-Start requires an IP Option and a TCP Option 🧚.
12.1. IP Option
Quick-Start requires both an IPv4 Option Number (Section 3.1) and an IPv6 Option Number (Section 3.2) 💜.
IPv4 Option Number:
Copy Class Number Value Name
---- ----- ------ ----- ----
0 00 25 25 QS - Quick-StartIPv6 Option Number [RFC2460]:
HEX act chg rest
--- --- --- -----
6 00 1 00110 Quick-StartFor the IPv6 Option Number, the first two bits mean the IPv6 node may skip over this option and keep processing the header if it doesn't recognize the option type. The third bit means the Option Data may change en-route 🫧.
In both cases, this document should be listed as the reference document 📝.
12.2. TCP Option
Quick-Start requires a TCP Option Number (Section 4.2) 🌸.
TCP Option Number:
Kind Length Meaning
---- ------ ------------------------------
27 8 Quick-Start ResponseThis document should be listed as the reference document 💖.
13. Conclusions ✨
So, the big picture 🦋. We're presenting Quick-Start as a simple, understandable, and incrementally deployable mechanism. It would be enough to let some connections start up with large initial rates, or large initial congestion windows, in over-provisioned, high-bandwidth environments. We expect more and more of those environments to show up, and Quick-Start, or another mechanism with similar power, could really benefit a wide range of traffic 🚀. We're also presenting Quick-Start as an open invitation 💌. We want the community to give feedback and run experiments on issues relating to Quick-Start, so come hang and help 🫶.
14. Acknowledgements 🎀
The authors want to thank Mark Handley for discussions of these issues 🙏. They also thank the End-to-End Research Group, the Transport Services Working Group, and members of IPAM's program on Large-Scale Communication Networks, for both positive and negative feedback on this proposal 💅. Thank you to Srikanth Sundarrajan for the initial implementation of Quick-Start in the NS simulator, and for the initial simulation study 🧁. Many thanks to David Black and Joe Touch for extensive feedback on Quick-Start and IP tunnels 🌷. The authors also thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi, and Vern Paxson for feedback 💜. Thanks also to Gorry Fairhurst for suggesting that the QS Nonce be added to the Report of Approved Rate 🍓.
The version of the QS Nonce in this document is based on a proposal from Guohan Lu [L05]. Earlier versions of this document contained an eight-bit QS Nonce, and later versions discussed the possibility of a four-bit QS Nonce 🧚♀️.
This document builds upon the concepts described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of the text on Quick-Start in tunnels was borrowed directly from RFC 3168 📚.
This document is the development of a proposal originally by Amit Jain for Initial Window Discovery 🌈.
Appendix A. Related Work 🔍
The Quick-Start proposal, taken together with HighSpeed TCP [RFC3649] or other transport protocols for high-bandwidth transfers, could go a significant way towards extending the range of performance for best-effort traffic in the Internet 🚄. However, there are plenty of things Quick-Start would not accomplish 😬. Quick-Start is not a congestion control mechanism, and it wouldn't help make more precise use of the available bandwidth. That means it wouldn't achieve the goal of high throughput with low delay and low packet-loss rates. Quick-Start also wouldn't give routers more control over the decrease rates of active connections.
On top of that, any evaluation of Quick-Start has to discuss the relative benefits of approaches that use no explicit information from routers, and approaches that use more fine-grained feedback from routers as part of a larger congestion control mechanism. We cover several classes of proposals in the sections below 🧐.
A.1. Fast Start-Ups without Explicit Information from Routers
One possibility is for senders to use information from the packet streams to learn about the available bandwidth, without explicit information from routers 🌊. These techniques wouldn't allow a start-up as fast as Quick-Start gives in an underutilized environment, because you already have to have sent some packets before you can use the packet stream to learn about available bandwidth. But these techniques could still allow a start-up considerably faster than the current Slow-Start 🏃♀️. It seems clear that approaches without explicit feedback from the routers will be strictly less powerful than approaches with explicit feedback. It's also possible that approaches more aggressive than Slow-Start are possible without the complexity of getting explicit feedback from routers 🤔.
Periodic packet streams
[JD02] explores the use of periodic packet streams to estimate the available bandwidth along a path 📈. The idea is that the one-way delays of a periodic packet stream show an increasing trend when the stream's rate is higher than the available bandwidth, because a queue builds up. [JD02] says the proposed mechanism doesn't cause significant increases in network utilization, losses, or delays when one flow does it at a time. But the approach could be problematic if a number of flows did it concurrently 😳. [JD02] also gives an overview of some of the earlier work on inferring the available bandwidth from packet trains 📚.
Swift-Start
The Swift Start proposal from [PRAKS02] combines packet-pair and packet-pacing techniques 🏎️. It uses an initial congestion window of four segments to estimate the available bandwidth along the path. That estimate is then used to dramatically increase the congestion window during the second RTT of data transmission ⚡.
SPAND
In the TCP/SPAND proposal from [ZQK00] for speeding up short data transfers, network performance information would be shared among many co-located hosts to estimate each connection's fair share of the network resources 🤝. Based on that estimate and the transfer size, the TCP sender would determine the optimal initial congestion window size. The TCP/SPAND design uses a performance gateway that monitors all traffic entering and leaving an organization's network 🏢.
Sharing information among TCP connections
The Congestion Manager [RFC3124] and TCP control block sharing [RFC2140] both propose sharing congestion information among multiple TCP connections with the same endpoints 👯. With the Congestion Manager, a new TCP connection could start with a high initial cwnd, if it was sharing the path and the cwnd with a pre-existing TCP connection to the same destination that had already obtained a high congestion window. RFC 2140 discusses ensemble sharing, where an established connection's congestion window could be `divided up' to be shared with a new connection to the same host. But neither approach covers a connection to a new destination with no existing or recent connection, and therefore no congestion control state, to that destination 🙃.
Continued research on how far TCP and other transport protocols can go in learning about available bandwidth without explicit feedback from the router seems useful. Still, there are several fundamental advantages to explicit feedback from routers 💅.
- Explicit feedback is faster than implicit feedback: One advantage of explicit feedback from the routers is that it lets the transport sender reliably learn of available bandwidth in one round-trip time ⏱️.
- Explicit feedback is more reliable than implicit feedback: Techniques that try to assess available bandwidth at connection start-up using implicit techniques are more error-prone than techniques that involve every element in the network path 🎯. Explicit information from the network can be wrong, but it has a much better chance of being appropriate than an end-host trying to estimate an appropriate sending rate using "block box" probing techniques of the entire path 🧩.
A.2. Optimistic Sending without Explicit Information from Routers ✨
Okay so another idea that's been floated [S02] is for the sender to just start with a big initial window 💅 without asking the routers for permission first, and without any bandwidth estimation techniques. The first packet of that initial window would carry info like the size or sending rate of the window. The plan is that congested routers would read that info from the first data packet and drop or delay many or all of the packets from that window. That way, a flow's optimistically large initial window wouldn't force a router to drop packets from competing flows 🫶. Still, this approach would seem to need some way for the sender to make sure the routers along the path actually understand the mechanism for marking the first packet of a large initial window 🤔.
Obviously, there are a bunch of questions to think about with optimistic sending 👀:
- (1) Incremental deployment: One question is the potential complications of incremental deployment, where some of the routers along the path might not understand the packet information describing the initial window.
- (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 is the potential role of optimistic senders in amplifying the damage done by a Distributed Denial of Service (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 is quantifying 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 that are kinda similar to Quick-Start, where the transport protocol collects explicit information from the routers along the path 🧚.
An IP Option about the free buffer size: In related work, [P00] investigates a slightly different IP option for TCP connections to discover the available bandwidth along the path. In that proposal, the IP option would query the routers along the path about the smallest available free buffer size. Also, the IP option would have been sent after the initial SYN exchange, when the TCP sender already had an estimate of the round-trip time.
The Performance Transparency Protocol: The Performance Transparency Protocol (PTP) includes a proposal for a single PTP packet that would collect information from routers along the path from the sender to the receiver [W00]. For example, a single PTP packet could be used to determine the bottleneck bandwidth along a path.
ETEN: Additional proposals for end nodes to collect explicit information from routers include one variant of Explicit Transport Error Notification (ETEN), which includes a cumulative mechanism to notify endpoints of aggregate congestion statistics along the path [KAPS02]. (A second variant in [KSEPA04] does not depend on cumulative congestion statistics from the network.)
A.4. Fast Start-Ups with more Fine-Grained Feedback from Routers 🦋
Proposals for more fine-grained, congestion-related feedback from routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking [K03]. Appendix B.6 discusses in more detail the relationship between Quick-Start and proposals for more fine-grained per-packet feedback from routers.
XCP: Proposals, such as XCP for new congestion control mechanisms based on more feedback from routers, are more powerful than Quick-Start, but also are more complex to understand and more difficult to deploy. XCP routers maintain no per-flow state, but provide more fine-grained feedback to end-nodes than the one-bit congestion feedback of ECN. The per-packet feedback from XCP can be positive or negative, and specifies the increase or decrease in the sender's congestion window when this packet is acknowledged. XCP is a full-fledge congestion control scheme, whereas Quick-Start represents a quick check to determine if the network path is significantly underutilized such that a connection can start faster and then fall back to TCP's standard congestion control algorithms.
AntiECN: The AntiECN proposal is for a single bit in the packet header that routers could set to indicate that they are underutilized. For each TCP ACK arriving at the sender indicating that a packet has been received with the Anti-ECN bit set, the sender would be able to increase its congestion window by one packet, as it would during slow-start.
A.5. Fast Start-Ups with Lower-Than-Best-Effort Service 🌈
There have been proposals for routers to provide a Lower Effort differentiated service that would be lower than best effort [RFC3662]. Such a service could carry traffic for which delivery is strictly optional, or could carry traffic that is important but that has low priority in terms of time. Because it does not interfere with best-effort traffic, Lower Effort services could be used by transport protocols that start up faster than slow-start. For example, [SGF05] is a proposal for the transport sender to use low-priority traffic for much of the initial traffic, with routers configured to use strict priority queueing.
A separate but related issue is that of below-best-effort TCP, variants of TCP that would not rely on Lower Effort services in the network, but would approximate below-best-effort traffic by detecting and responding to congestion sooner than standard TCP. TCP Nice [V02] and TCP Low Priority (TCP-LP) [KK03] are two such proposals for below-best-effort TCP, with the purpose of allowing TCP connections to use the bandwidth unused by TCP and other traffic in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use the default slow-start mechanisms of TCP.
We note that Quick-Start is quite different from either a Lower-Effort service or a below-best-effort variant of TCP. Unlike these proposals, Quick-Start is intended to be useful for best-effort traffic that wishes to receive at least as much bandwidth as competing best-effort connections 👑.
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. Yikes, bestie, this is the part to take seriously 😭.
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 🧚
Okay bestie, so RSVP [RFC2205] could actually be used as the bearer protocol for carrying the Quick-Start Requests, with some modifications 💅. Routers are expected to process RSVP packets way more thoroughly than regular IP packets, so sending a Quick-Start rate request in an RSVP packet kinda seems like the iconic choice 😭. BUT Quick-Start with RSVP would need a few differences from how RSVP is normally used, ngl. Quick-Start wouldn't need to periodically refresh soft state, because Quick-Start doesn't need per-connection state in routers ✨. The Quick-Start Requests would travel downstream from the sender to the receiver in RSVP Path messages, which is the opposite of the usual RSVP energy where reservations start at the receiver 🙈. And the Quick-Start Response would go through transport-level or application-level mechanisms instead of the RSVP Resv message, periodt.
If RSVP was used to carry a Quick-Start Request, a new "Quick-Start Request" class object would be added to the RSVP Path message that goes from sender to receiver 🎀. This object would hold the rate request field, plus the usual common length and type fields. The Send_TTL field in the RSVP common header could do the job of the QS TTL field 🌸. The Quick-Start capable routers along the path would check 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 didn't 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 matching transport protocol header, the same way we talked about with IP options earlier 💜. And if the RSVP message with the Quick-Start Request object got dropped somewhere along the path, the transport sender would just go ahead with the normal congestion control procedures, no drama 🫶.
Much of the tea about the benefits and drawbacks of using ICMP for making the Quick-Start Request also applies to the RSVP case 👑. If the Quick-Start Request was sent in a separate packet instead of as an IP option, the transport protocol packet delivery wouldn't get delayed by IP option processing at the routers, and the initial transport packets would reach their destination more reliably ⭐. The possible downsides of using ICMP and RSVP are also expected to be pretty similar: middleboxes in the network might not be able to forward the Quick-Start Request messages, and IP tunnels might cause problems when 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 requirement for this function is that it should have a sufficiently wide range for the requested rate. There's no need for overly fine-grained precision in the requested rate 🙈. Similarly, while it would be attractive for the encoding function to be easy to compute, end-nodes and routers could also just store a table mapping the value N in the Rate Request field to 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 is 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. So 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 good enough for the Rate Request, then the encoding function with the most range would be for the requested rate to be K*2^N, where N is the value in the Rate Request field and K is some constant 🦋. For N=0, the rate request is set to zero, no matter what the encoding function is 🫧. For example, with K=40,000 and an eight-bit Rate Request field, the request range would go from 80 Kbps to 40*2^255 Kbps. Honestly, that's clearly 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 wanting to start up with a higher initial sending rate should be encouraged to use other mechanisms, like explicitly reserving bandwidth 🎀. If an upper limit of 1.3 Gbps isn't 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, which 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 📶. So 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 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 isn't acceptable, then extra bits could be used for the Rate Request field 🧁.
If the granularity of factors of two was too coarse, 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's 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 only applies to the bytes of data payload, and doesn't include the bytes in the TCP or IP packet headers 🫧. Other transport protocols could conceivably use the Quick-Start Request directly in packets per second, or could translate it into 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 it 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 📦. So for a Quick-Start Request in bytes per second, it makes most sense for it 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, since 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 🫠. Still, this rough estimate seems sufficient, 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] 📜. Still, it's probably often the case that this MSS also applies as an upper bound on the MSS the TCP sender uses when sending 🤷♀️.
We note that the sender doesn't necessarily know the Path MTU when the Quick-Start Request is sent, or when the initial window of data is sent 🗺️. So 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 extra complication of estimating the bandwidth usage added by the packet headers 🧾.
We chose 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? 💅🎀
okay so bestie, this is where we figure out what the Rate Request field is actually asking for when a Quick-Start Request shows up in the middle of a connection 🦋 there are two possible semantics for it:
(1) Total Rate: the Rate Request is the requested total rate for the connection, including the current rate; or
(2) Additional Rate: the 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 💤 so (1) and (2) are literally the same thing, no difference at all ✨ but a Quick-Start Request can also be sent in the middle of a connection that has not been idle 👀 like after a mobility event, or after an application-limited period when the sender is suddenly ready to send at a much higher rate 🚀 in that case there can be a big difference between (1) and (2). so in this section we're going to look at the tradeoffs between the two options and explain why we went with the `Total Rate' semantics 💖
the Total Rate semantics makes it way easier for routers to "allocate" the same rate to all connections 🍓 this is lowkey the fairness queen move, and it helps convergence times between old and new connections 👑 with the Additional Rate semantics, the router wouldn't necessarily know the current sending rates of the flows asking for extra rate, so it wouldn't have enough info to use fairness as a metric when granting requests 😭 with Total Rate, fairness is automatic 🌈 the router isn't granting requests for additional bandwidth without knowing what the different flows are already sending. iconic 💅
the Additional Rate semantics also lends itself to gaming by the connection 🙈 senders could send frequent Quick-Start Requests in the hope of getting a higher rate. if the router grants the same maximum rate for every rate request, there's basically no benefit to a connection spamming rate requests over and over 🧚 but if the router grants an additional rate with each request, over and above the current sending rate, then it's in a connection's best interest to send as many rate requests as possible, even if very few of them actually get granted 💀 not it 😤
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 🌊
okay now let's talk about what happens when a Quick-Start packet gets lost 😭 Section 4.6 discusses TCP's response to losing a Quick-Start packet in the initial window 💅 this section covers several alternate responses 🎀
one possible alternative to reverting to the default Slow-Start after losing a Quick-Start packet from the initial window would have been to halve the congestion window and keep going in congestion avoidance ✨ but ngl, that would not have been a desirable response for either the connection or the network as a whole 🙈 losing a packet in the initial window means Quick-Start failed to find an appropriate congestion window, so the congestion window after halving could easily be wrong too 💀
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 🦋 but this approach would implicitly assume that the number of Quick-Start packets delivered is a good indication of the right available bandwidth for that flow, even though other packets from that same window got dropped in the network 😭 and it would also assume 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 assumption would need more analysis at this point, especially in a network with a range of packet dropping mechanisms at the router, so we cannot recommend it at this time 🍓
another drawback of approaches that don't revert back to slow-start when a Quick-Start packet in the initial window is dropped is that they 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, that diminishes the benefit a receiver would get from a Quick-Start request that resulted in a dropped or ECN-marked packet 🫶 main character energy for the sender, no cap 👑
B.6. Why Not Include More Functionality? 💅
Okay so this proposal for Quick-Start is a pretty coarse-grained mechanism 🧚. It lets a connection use a higher sending rate along underutilized paths, but it does not try to be a next-generation transport protocol or congestion control mechanism, and it doesn't chase the goal of very high throughput with very low delay. Appendix A.4 talks about a bunch of proposals (like XCP, MaxNet, and AntiECN) that give more fine-grained per-packet feedback from routers than the current congestion control mechanisms, and they go after those more ambitious goals 🚀.
Compared to proposals like XCP and AntiECN, Quick-Start offers way less control 🙈. Quick-Start doesn't try to provide a new congestion control mechanism. It just gets permission from routers for a higher sending rate at start-up, or after an idle period. Honestly it's kind of an "anti-congestion-control" mechanism that's only useful when all the routers along the path are significantly underutilized 😭. So it's of no use for aiming at high link utilization, fairness in a high-utilization scenario, controlling queueing delay during high utilization, or anything of the like 💀.
At the same time, Quick-Start would allow larger initial windows than something like AntiECN would, it requires less input to routers than XCP (no cwnd and RTT fields, for example), and it would need less frequent feedback from routers than any new congestion control mechanism 🌸. So Quick-Start is way less powerful than proposals like XCP and AntiECN, but just as powerful or more powerful on the specific issue of allowing larger initial windows. Also (we think!) it's more amenable to incremental deployment in the current Internet 🦋.
We don't discuss XCP-style proposals in detail. We just note there are a number of open questions 🤔. One question is whether there's a pressing need for more sophisticated congestion control mechanisms like XCP in the Internet. Quick-Start is inherently a pretty crude tool that doesn't deliver any assurances about keeping high link utilization and low queueing delay. It's designed for environments that are significantly underutilized, and it 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 fairly 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 got implemented, it's still reasonable to have a separate mechanism, like 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 fine-grained per-packet proposals like XCP is that XCP is designed to give robust performance even when different packets within a connection routinely follow different paths 🛤️. XCP achieves relatively robust performance with multipath routing by using per-packet feedback. 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 📦. So Quick-Start could be problematic in an environment where some fraction of the packets in a window take path A and the rest 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 per-packet feedback proposals 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. That would be more like other proposals, such as anti-ECN, which use a single bit of feedback from routers to indicate that the sender can increase as fast as slow-starting, in response to this particular packet acknowledgement. In general, there is probably considerable power in fine-grained proposals with only two bits of feedback, indicating that the sender should decrease, maintain, or increase the sending rate or window when this packet is acknowledged. However, the power of Quick-Start would be considerably limited if it was restricted to only two bits of feedback. It seems likely that determining the initial sending rate fundamentally requires more bits of feedback from routers than the steady-state, per-packet feedback used to increase or decrease the sending rate 🧠.
On a more practical level, one difference between Quick-Start and per-packet feedback proposals 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 gives a quick summary of the differences between Quick-Start and proposals for per-packet congestion control feedback 📊.
Proposals for
Quick-Start Per-Packet Feedback
+------------------+----------------------+----------------------+
Semantics: | Allowed sending rate | Change in rate/window,
| per connection. | per-packet.
+------------------+----------------------+----------------------+
Relationship to | In addition. | Replacement.
congestion ctrl: | |
+------------------+----------------------+----------------------+
Frequency: | Start-up, or after | Every packet.
| an idle period. |
+------------------+----------------------+----------------------+
Limitations: | Only useful on | General congestion
| underutilized paths.| control mechanism.
+------------------+----------------------+----------------------+
Input to routers: | Rate request. |RTT, cwnd, request (XCP)
| | None (Anti-ECN).
+------------------+----------------------+----------------------+
Bits of feedback: | Four bits for | A few bits would
| rate request. | suffice?
+------------------+----------------------+----------------------+
Table 3: Differences between Quick-Start and Proposals for
Fine-Grained Per-Packet Feedback.A separate question concerns whether mechanisms, such as Quick-Start, in combination with HighSpeed TCP and other changes in progress, would make a significant contribution towards meeting some of these needs for new congestion control mechanisms 🤷♀️. This could be viewed as a positive step towards meeting some of the more pressing current needs with a simple and reasonably deployable mechanism, or alternately, as a negative step of unnecessarily delaying more fundamental changes. Without answering this question, we would note that our own approach tends to favor the incremental deployment of relatively simple mechanisms, as long as the simple mechanisms are not short-term hacks, but mechanisms that lead the overall architecture in the fundamentally correct direction 🌈.
B.7. Alternate Implementations for a Quick-Start Nonce 🔐
B.7.1. An Alternate Proposal for the Quick-Start Nonce 🧁
An alternate proposal for the Quick-Start Nonce from [B05] would be for an n-bit field for the QS Nonce, with the sender generating a random nonce when it generates a Quick-Start Request. Each router that reduces the Rate Request by r would hash the QS nonce r times, using a one-way hash function such as MD5 [RFC1321] or the secure hash 1 [SHA1]. The receiver returns the QS nonce to the sender. Because the sender knows the original value for the nonce, and the original rate request, the sender knows the total number of steps s that the rate has been reduced. The sender then hashes the original nonce s times to check whether the result is the same as the nonce returned by the receiver.
This alternate proposal for the nonce would be considerably more powerful than the QS nonce described in Section 3.4, but it would also require more CPU cycles from the routers when they reduce a Quick-Start Request, and from the sender in verifying the nonce returned by the receiver. As reported in [B05], routers could protect themselves from processor exhaustion attacks by limiting the rate at which they will approve reductions of Quick-Start Requests 🛡️.
Both the Function field and the Reserved field in the Quick-Start Option would allow the extension of Quick-Start to use Quick-Start requests with the alternate proposal for the Quick-Start Nonce, if it was ever desired ⭐.
B.7.2. The Earlier Request-Approved Quick-Start Nonce 🕰️
okay so an earlier version of this doc had a Request-Approved Quick-Start Nonce (QS Nonce) 🧚. The sender set it to a non-zero, `random' eight-bit number, and it also set a QS TTL to the same value as the TTL in the IP header 💅. The transport receiver would send that nonce back to the transport sender in the Quick-Start Response. A router could deny the Quick-Start Request by not decrementing the QS TTL field, by zeroing the QS Nonce field, or by deleting the Quick-Start Request from the packet header 🙈. The nonce was there to protect against broken downstream routers, or against misbehaving TCP receivers who might be tempted to lie about whether the Rate Request got approved 👀. Now that protection comes from the QS Nonce, the random initial value for the QS TTL field, and 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 ✨.
ngl the old setup was kind of iconic 🦋. With the old nonce and the QS TTL set equal to the IP TTL, the Quick-Start Request was self-terminating. It would stop at the first participating router after a non-participating router was encountered on the path. That meant way less wasted option processing for routers 💖. In the current spec, the self-terminating property comes from 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 spec 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. That's the price of a design that makes it hard 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 apps like streaming media, Internet telephony, and online games 🎮. In DCCP, the application gets to choose a congestion control mechanism. The currently-specified Congestion Control Identifiers (CCIDs) are CCID 2 for TCP-like congestion control, and CCID 3 for TCP Friendly Rate Control (TFRC), an equation-based form of congestion control. For a more detailed description of DCCP and congestion control mechanisms, check out [RFC4340] 📚.
Because CCID 3 uses a rate-based congestion control mechanism, it brings some new issues to the table when you use Quick-Start with transport protocols 🍓. This doc doesn't try to specify the use of Quick-Start with DCCP. However, it does talk about some of the issues that might arise 🧐.
When you're thinking about using Quick-Start with CCID 3 to request a higher initial sending rate, these questions come up 💅:
(1) How does the sender respond if a Quick-Start packet is dropped?
As in TCP, if an initial Quick-Start packet is dropped, the CCID 3 sender should revert to the congestion control mechanisms it would have used if the Quick-Start Request had not been approved 😭.
(2) When does the sender decide there has been no feedback from the receiver?
Unlike TCP, CCID 3 doesn't use acknowledgements for every packet, or for every other packet 🙃. Instead, 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 comes up about how the sending rate should be reduced after a period of no feedback from the receiver 🤔. Just like with TCP, the default CCID 3 response of halving the sending rate isn't 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. So if a CCID 3 sender uses a Quick-Start Request, special rules might be required to handle its response to a period of no feedback from the receiver about the Quick-Start packets 🌸.
Similarly, when you're thinking about using Quick-Start with CCID 3 to request a higher sending rate after an idle period, these questions come up 🦋:
(1) What rate does the sender request?
Just like in TCP, there's a straightforward answer 🙌. The sender knows the current loss event rate, either from its own calculations or from feedback from the receiver, and can work out the sending rate allowed by that loss event rate. That's the upper bound on the sending rate that the CCID 3 sender should request. 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 doesn't let the sender send more than twice as fast as the receiver has reported received in the most recent feedback message 🚀.
(2) What is the response to loss?
The response to the loss of Quick-Start packets should be to return to the sending rate that would have been used if Quick-Start had not been requested 💜.
(3) When does the sender decide there has been no feedback from the receiver?
Same as with the initial sending rate, it would seem prudent to reduce the sending rate if no feedback is received from the receiver in at least two round-trip times 🧠. It seems likely that, in this case, the sending rate should be reduced to the sending rate that would have been used if no Quick-Start Request had been approved ✨.
Appendix D. Possible Router Algorithm 🧮
This spec doesn't tightly define the algorithm a router uses when it decides 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 the algorithm a particular router uses is considered a local policy decision. Also, the authors believe more experimentation with router algorithms is needed to really understand the dynamics that different algorithms impose 🔬. But this appendix gives one particular algorithm 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, that 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's underutilized enough to approve Quick-Start Requests (of some size) 👀.
First, there's 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. So this method keeps N*S seconds of history. The algorithm reacts rapidly to increases in link utilization. In [SAF06], S is set to 0.15 seconds, and experiments use values for N ranging from 3 to 20 🌟.
Second, there's the "target" algorithm for processing incoming Quick-Start Rate Requests (also from [SAF06]) 🎯. It 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 the one above), and an estimate of the potential bandwidth from recent Quick-Start approvals 🫶.
Tracking the potential bandwidth from recent Quick-Start approvals is another place where local policy decides how it gets 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. It then uses 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), which is the fraction of the outgoing link bandwidth that represents the router's notion of "significantly underutilized" 🍰. If the utilization, boosted 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 boosted 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 so the bandwidth allocated wouldn't push the utilization past 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 since Rate Requests are fairly coarse, the approved rate should be rounded down when it doesn't fall exactly on one of the rates allowed by the encoding scheme 💫.
Routers that want to keep close track of the allocated Quick-Start bandwidth could use Approved Rate reports 🕵️♀️. Those reports tell them when rate requests had been decremented downstream in the network, and also when a sender begins to use the approved Quick-Start Request 🎀.
Appendix E. Possible Additional Uses for the Quick-Start Option 🎀
okay so bestie, this appendix is basically a brainstorm session for what else the Quick-Start Option could do 💅✨ the Quick-Start Option has a four-bit Function field in its third byte, which means new functions can be defined later without redesigning the whole thing 🦋 that's the iconic part! 🙈 the Function field makes it super easy to add new stuff 💖
here are some of the possible extra uses that got talked about for Quick-Start 🌸
Report of Current Sending Rate: 🧚 a Quick-Start Request with the Report of Current Sending Rate codepoint set in the Function field would use the Rate Request field to report the sender's current estimated sending rate for that connection 📊 this could ride along with a second Quick-Start Request in the same packet that has a standard rate request, for a connection that's using Quick-Start to speed up its current sending rate 🚀
Request to Increase Sending Rate: 💜 a codepoint for Request to Increase Sending Rate in the Function field would say the connection isn't idle or just starting up, but is trying to use Quick-Start to increase its current sending rate 🔥 this codepoint would NOT change what the Rate Request field means 😌
RTT Estimate: 🌈 if a codepoint for RTT Estimate were used, a field for the RTT Estimate would hold one or more bits giving the sender's rough guess of the round-trip time, if it's known 🕐 e.g., the sender could estimate whether the RTT was greater or less than 200 ms ✨ or, if the sender had an estimate of the RTT when it sends the Rate Request, the two-bit Reserved field at the end of the Quick-Start Option could be used for a coarse-grained encoding of the RTT 🫶
Informational Request: 🔮 an Informational Request codepoint in the Function field would mark a request as purely informational 👀 its whole job is for the sender to find out whether 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 that approves an Informational Request would NOT count that as approval for Quick-Start bandwidth to actually be used, and it would have NO obligation to approve a similar standard Quick-Start Request one round-trip time later 😭 an Informational Request with a rate request of zero could be used by the sender to find out if all of the routers along the path supported Quick-Start 🛣️
Use Format X for the Rate Request Field: 🍓 a Quick-Start codepoint for Use Format X for the Rate Request Field would indicate that an alternate format was being used for the Rate Request field 🧩
Do Not Decrement: 🙅♀️ a Do Not Decrement codepoint could be used for a Quick-Start Request where the sender would rather have the request denied than 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 ✨
okay bestie, this is the big reading list 📚 every single one of these is a source the spec leans on, so I'm keeping every detail exactly as it was 🫶
- [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
- [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
- [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
- [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
- [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
- [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
- [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August 1999.
- [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
- [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
- [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
- [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
- [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003.
- [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
- [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
- [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
- [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
- [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
- [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
- [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP with Larger Initial Windows. ACM Computer Communication Review, July 1998.
- [B05] Briscoe, B., "Review: Quick-Start for TCP and IP", <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html>, November 2005.
- [BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of the new GSM Phase 2+ General Packet Radio Service. IEEE Communications Magazine, pages 94--104, August 1997.
- [GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, September 2002.
- [H05] P. Hoffman, email, October 2005. Citation for acknowledgement purposes only.
- [HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics, Proc. USENIX Security Symposium 2001.
- [Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM.
- [JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP Throughput, SIGCOMM 2002.
- [K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. <http://www.seas.upenn.edu/~kunniyur/>.
- [KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. Sterbenz. Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks. Technical Report No. 8333, BBN Technologies, March 2002. <http://www.icir.org/mallman/papers/>.
- [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet Congestion Control for Future High Bandwidth-Delay Product Environments. ACM Sigcomm 2002, August 2002. <http://ana.lcs.mit.edu/dina/XCP/>.
- [KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003.
- [KSEPA04] Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig Partridge, Mark Allman. Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks. Computer Networks, 46(3), October 2004.
- [L05] Guohan Lu, Nonce in TCP Quick Start, September 2005. <http://www.net-glyph.org/~lgh/nonce-usage.pdf>.
- [MH06] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", Work in Progress, December 2006.
- [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring Interactions Between Transport Protocols and Middleboxes, Internet Measurement Conference 2004, August 2004. <http://www.icir.org/tbit/".
- [MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. Computer Communications Review, April 2005.
- [MaxNet] MaxNet Home Page, <http://netlab.caltech.edu/~bartek/maxnet.htm>.
- [P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection, report to John Heidemann, 2000, private communication. Citation for acknowledgement purposes only.
- [PABL+05] Ruoming Pang, Mark Allman, Mike Bennett, Jason Lee, Vern Paxson, Brian Tierney. A First Look at Modern Enterprise Traffic. ACM SIGCOMM/USENIX Internet Measurement Conference, October 2005.
- [PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical Report No. 8339, BBN Technologies, March 2002. <http://www.icir.org/mallman/papers/>.
- [RW03] Mattia Rossi and Michael Welzl, On the Impact of IP Option Processing, Preprint-Reihe des Fachbereichs Mathematik - Informatik, No. 15, Institute of Computer Science, University of Innsbruck, Austria, October 2003.
- [RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option Processing - Part 2, Preprint-Reihe des Fachbereichs Mathematik - Informatik, No. 26, Institute of Computer Science, University of Innsbruck, Austria, July 2004.
- [S02] Ion Stoica, private communication, 2002. Citation for acknowledgement purposes only.
- [SAF06] Pasi Sarolahti, Mark Allman, and Sally Floyd. Determining an Appropriate Sending Rate Over an Underutilized Network Path. February 2006. <http://www.icir.org/floyd/quickstart.html>.
- [SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work in Progress session, August 2005, <https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf>.
- [SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce, Washington, D.C., publication 180-1, April 1995.
- [SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick Start with NS-2. Class Project, December 2002. Not publicly available; citation for acknowledgement purposes only.
- [V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A Mechanism for Background Transfers. OSDI 2002.
- [VH97] V. Visweswaraiah and J. Heidemann, Improving Restart of Idle TCP Connections, Technical Report 97-661, University of Southern California, November 1997.
- [W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE International Performance, Computing, And Communications Conference), Phoenix, Arizona, USA, 20-22 February 2000. <http://www.welzl.at/research/publications/>.
- [ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the Constancy of Internet Path Properties, Proc. ACM SIGCOMM Internet Measurement Workshop, November 2001.
- [ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data Transfers: Theory, Architectural Support, and Simulation Results, NOSSDAV 2000, June 2000.
Authors' Addresses 🌸
these are the people who wrote it, so here's where to find them 💖
Sally Floyd
Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research)
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Mark Allman
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: (440) 235-1792
EMail: mallman@icir.org
URL: http://www.icir.org/mallman/
Amit Jain
F5 Networks
EMail: a.jain@f5.com
Pasi Sarolahti
Nokia Research Center
P.O. Box 407
FI-00045 NOKIA GROUP
Finland
Phone: +358 50 4876607
EMail: pasi.sarolahti@iki.fiFull Copyright Statement ✨
Okay bestie, the legal bits 📜🎀 Copyright (C) The IETF Trust (2007) 💖. This document is subject to the rights, licenses, and restrictions in BCP 78, and except for what's set out there, the authors keep all their rights 🫶.
This document and the info in it are given "AS IS" 💅, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES 😭, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE 🙈.
Intellectual Property
Lowkey the IETF isn't taking a side on whether any Intellectual Property Rights or other rights that might be claimed for the technology in this document are valid or in scope 🌸. It also isn't saying whether any license under those rights might be available, and it hasn't done any independent digging to find them 🔍. For the procedures on rights in RFC documents, check out BCP 78 and BCP 79 📚.
IPR disclosures sent to the IETF Secretariat, any assurances of licenses that might be offered, and the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this specification can all be found in the IETF online IPR repository at http://www.ietf.org/ipr 🦋.
The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard 🧚. Send that info to the IETF at ietf-ipr@ietf.org 💌. Main character energy for sharing it early 👑.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society 🌈🫶. Thank you, Internet Society, you're iconic 💜✨.
📦 where this page comes from
- ietf: rfc4782 2007-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms