Chapter 3 answered two hard questions. How do you deliver bytes reliably over a network that guarantees nothing, and how do you do it without melting the network? Then it showed both answers being rebuilt one layer up.
What this page is for
- A map of everything the chapter introduced, with every node linking back to the section that taught it.
- A recap of the argument, in the order the chapter made it.
- A comparison of the three transport options, on the axes that separate them.
- Every number worth remembering, in one sortable table.
- An honest list of where the book itself needs care.
What this chapter was for
Chapter 2 asked applications what they wanted from the network. Two of those wants were hard: deliver my bytes correctly, and do not overwhelm the network doing it.
The chapter answered each twice — once in principle, once as TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 — and that alternation is worth keeping in your head. Section 3.4 built reliable transfer from nothing so that section 3.5 could be read as which of those pieces TCP chose. Section 3.6 established what congestion costs so that section 3.7 could be read as what TCP does about it.
Hover an idea to see what it connects to. Click one to go back to the section that taught it.
Hover a node to dim everything it does not touch. Click one to return to the section that taught it. Follow the arrows out of "sequence numbers" — almost the whole chapter depends on that one idea.
Read this map as a list
- logical communication (§3.1) — connects to mux / demux
- mux / demux (§3.2) — connects to logical communication, UDP
- UDP (§3.3) — connects to mux / demux, checksum, QUIC
- checksum (§3.3.2) — connects to UDP, sequence numbers
- sequence numbers (§3.4.1) — connects to checksum, timers, pipelining, byte sequence numbers
- timers (§3.4.1) — connects to sequence numbers, pipelining, RTT estimation
- pipelining (§3.4.2) — connects to sequence numbers, timers, Go-Back-N, selective repeat, bandwidth-delay product
- Go-Back-N (§3.4.3) — connects to pipelining, selective repeat, fast retransmit
- selective repeat (§3.4.4) — connects to pipelining, Go-Back-N, fast retransmit, per-stream delivery
- bandwidth-delay product (§3.4.2) — connects to pipelining, flow control
- QUIC (§3.8) — connects to per-stream delivery, HTTP/3, UDP, AIMD — the saw tooth
- per-stream delivery (§3.8) — connects to QUIC, selective repeat
- HTTP/3 (§3.8) — connects to QUIC
- three-way handshake (§3.5.6) — connects to byte sequence numbers
- byte sequence numbers (§3.5.2) — connects to sequence numbers, three-way handshake, fast retransmit, flow control
- RTT estimation (§3.5.3) — connects to timers, fast retransmit, slow start
- fast retransmit (§3.5.4) — connects to Go-Back-N, selective repeat, byte sequence numbers, RTT estimation, slow start
- flow control (§3.5.5) — connects to byte sequence numbers, bandwidth-delay product
- causes and costs (§3.6) — connects to end-to-end vs assisted
- end-to-end vs assisted (§3.6.2) — connects to causes and costs, slow start, ECN · delay-based
- slow start (§3.7.1) — connects to end-to-end vs assisted, AIMD — the saw tooth, fast retransmit, RTT estimation
- AIMD — the saw tooth (§3.7.1) — connects to slow start, CUBIC, fairness, QUIC
- CUBIC (§3.7.1) — connects to AIMD — the saw tooth
- ECN · delay-based (§3.7.2) — connects to end-to-end vs assisted
- fairness (§3.7.3) — connects to AIMD — the saw tooth
The argument, in six steps
1 — What a transport protocol can and cannot promise
At one extreme a transport protocol can be a no-frills service offering only multiplexing and demultiplexing: that is UDP user datagram protocol Simple The Internet’s bare transport protocol: addressing and an error check, nothing else. Precise UDP, defined in RFC 768. It adds almost nothing to IP: source and destination port numbers for multiplexing and demultiplexing, a length, and a checksum, in an 8-byte header. There is no handshake, no connection state, no retransmission, no flow control and no congestion control, so an application using UDP keeps full control of what it sends and when. introduced in ch. 3 — open in glossary . At the other it can offer reliable delivery, and in principle delay and bandwidth guarantees.
But the services it can provide are constrained by the service model of the network layer beneath it. If IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 gives no delay or bandwidth guarantee, no transport protocol can manufacture one.
2 — Reliability can be built on unreliability
Section 3.4 showed that a transport protocol can provide reliable data transfer even when the network layer below is unreliable. There are many subtle points, but the task is accomplished by carefully combining acknowledgements, timers, retransmissions and sequence numbers.
And this is not a transport-layer trick. Reliable data transfer can be provided by link-, network-, transport- or application-layer protocols — any of the upper four layers can implement those four mechanisms. Engineers have independently built all four kinds over the years, though many have quietly disappeared.
QUIC (Quick UDP Internet Connections) Quick UDP Internet Connections A transport-like protocol built in the application layer over UDP, carrying HTTP/3. The IETF now treats QUIC as a name rather than an abbreviation. introduced in ch. 2 quic Simple An application-layer protocol over UDP that does TCP’s job, faster and per stream. Precise Quick UDP Internet Connections [Langley 2017, RFC 9000]: a connection-oriented, encrypted, congestion-controlled protocol implemented in the application layer on top of UDP. It merges the connection, authentication and encryption handshakes into one exchange, so setup costs fewer round trips than TCP plus TLS, and it provides reliable in-order delivery separately per stream. Its congestion control is based on TCP NewReno [RFC 6582]. HTTP/3 is built on it. introduced in ch. 3 — open in glossary , in section 3.8, is a living example at the application layer.
3 — TCP is complicated, and the application never sees it
Section 3.5 covered connection management, flow control, round-trip time estimation and reliable data transfer — and TCP is more complex than that description. The book deliberately left out a variety of patches, fixes and improvements that are widely implemented.
All of it is hidden from the application. A client opens a socket and pumps data into it. In the book’s phrase, the client-server application is blissfully unaware of TCP’s complexity.
4 — Congestion control is not optional
Sections 3.6 and 3.7 showed that congestion control is imperative for the well-being of the network. Without it a network can easily become gridlocked, with little or no data getting through end to end.
Classic TCP’s answer is end-to-end: additively increase the rate when the path seems congestion-free, multiplicatively decrease it when loss occurs. It also strives to give each connection through a congested link an equal share.
5 — And it is still changing
Newer variants try to find the sending rate more quickly than classic TCP (CUBIC). Others use a delay-based approach (Vegas, BBR (Bottleneck Bandwidth and Round-trip propagation time) Bottleneck Bandwidth and Round-trip propagation time A delay-based congestion-control protocol [Cardwell 2017] that Google uses on its B4 network and public servers (§3.7.2). introduced in ch. 3 ), or take explicit congestion notification from the network rather than inferring from loss.
The book is careful to say that while TCP congestion control has evolved for decades, it remains an area of intensive research and will likely keep evolving. Nothing on this page is settled.
6 — Establishment and slow start cost real time
The chapter examined in some depth the delay that connection establishment and slow start add. In many important scenarios they contribute significantly to end-to-end delay.
The number to hold: Lin’s 372 kB page needs 8 rounds of slow start — 1.44 seconds — against 29.76 ms of actual transmission. Forty-eight times more waiting than sending, and it is why section 3.8’s merged handshake was worth the trouble.
| UDP§3.3 | TCP§3.5–3.7 | QUIC§3.8 | |
|---|---|---|---|
| Layer | |||
| Reliable delivery | |||
| In-order delivery | |||
| Flow control | |||
| Congestion control | |||
| Connection setup | |||
| Header | |||
| Chosen when |
Cells marked ⓘ have a reason behind them — click to read it.
Read down a column for one protocol, or across a row to see the same decision made three ways.
| What | Value | |
|---|---|---|
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
Sort by section to revise in order, or read straight down. Click a value for where it came from.
Where the book itself needs care
This chapter has more misprints than the two before it, most of them cross-reference damage from the 8th edition’s renumbering. The ones that could actually mislead you:
- §3.5.2 says the flag field has 6 bits; Figure 3.29 draws 8, and only 8 makes the row add to 32. CWR (Congestion Window Reduced) Congestion Window Reduced The TCP header bit a sender sets to confirm it has reacted to an ECN Echo by halving its congestion window (§3.7.2). introduced in ch. 3 and ECE (ECN Echo) ECN Echo The TCP header bit a receiver sets to tell the sender that a datagram arrived carrying an ECN congestion mark (§3.7.2). introduced in ch. 3 were added later by RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 3168.
- §3.7 opens by pointing at “Section 7.3.1” and “Section 7.3.2”; it means 3.7.1 and 3.7.2.
- §3.7.3 cites Figures 3.55 and 3.56 where it means 3.56 and 3.57, and P41 inherits the slip.
- P55 cites a “TCP futures” subsection that does not exist in this edition. Section 3.7.1-cubic supplies the constants it needs.
- P50 says “repeat Problem 46”; it means P48.
- §3.7.1 cites RFC 3390 for an initial window of 1 MSS (maximum segment size) maximum segment size The largest amount of application data TCP puts in one segment. Typically 1,460 bytes. It limits the data, not the whole segment (§3.5.1). introduced in ch. 3 — that RFC is titled Increasing TCP’s Initial Window and sets it to 2–4.
Each is flagged on the page where it appears.
Check yourself
Check yourself — the whole chapter
0 of 6 answered1.What limits the services a transport protocol can offer?
2.Which four mechanisms did section 3.4 assemble into reliable data transfer?
3.The same four mechanisms could be implemented at which layers?
4.Summarise classic TCP congestion control in one line.
5.predictThe numbers table gives Lin's page as 1.44 s of slow start against 29.76 ms of transmission. What does that ratio tell you?
6.Chapter 1 divided the Internet into edge and core. Where does chapter 3 leave that journey?
Where this leaves the journey
Chapter 1 divided a computer network into the network edge and the network core. The edge covers everything that happens in the end systems.
Having now covered the application layer and the transport layer, the discussion of the network edge is complete. Every protocol in chapters 2 and 3 runs only in end systems; not one line of it executes in a router.
It is time to explore the core. That journey begins in the next two chapters, with the network layer, and continues into chapter 6 with the link layer.
The chapter in three lines
- Reliable transfer is built from three parts: a checksum to detect damage, an acknowledgement to report it, and a sequence number to tell a retransmission from a new packet. Everything from rdt2.0 to TCP is a rearrangement of those three.
- Flow control protects the receiver; congestion control protects the network. One is told its limit in a header field, the other must infer it from loss and delay.
- TCP’s rate is its congestion window congestion window Simple A sender-side limit on unacknowledged data, set by what the network seems able to take. Precise cwnd: a variable kept only at the sender, which together with rwnd bounds the unacknowledged data by LastByteSent − LastByteAcked ≤ min{cwnd, rwnd}. Roughly, the sender may send cwnd bytes per round-trip time, so its rate is about cwnd/RTT. Unlike rwnd it appears in no header — the network never states it, the sender infers it. introduced in ch. 3 — open in glossary divided by the round-trip time. So every algorithm in §3.7 — Reno, CUBIC, Vegas, BBR — is an argument about how that window should move.