Retransmission fixes a lost segment. It does nothing about why the segment was lost — and in the worst case, sending harder delivers less.
Words you will meet
- λ_in — the rate at which an application sends original data.
- λ′_in — the offered load: original data plus retransmissions.
- λ_out — the throughput actually measured at the receiver.
- Congestion collapse — the state where the network is busy and almost nothing useful arrives.
- Choke packet — a message a router sends straight back to a sender saying “I am congested”.
Why this matters
Loss usually happens because a router buffer overflowed. Section 3.5.4 showed 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 retransmitting whatever was lost — which treats the symptom, and not the cause: too many sources sending too fast.
Worse, retransmission makes the cause a little worse each time, by putting more traffic into a network that is already carrying more than it can. Something has to throttle the senders.
Like reliable data transfer, this is high on the book’s list of fundamentally important problems in networking. And as with reliable data transfer, the chapter does the principle first and TCP second.
A units warning, because this section changes them
Everywhere else in this book, R is a link rate in bits per second.
In this section the book writes “all router links have capacity R bytes/sec”. The graphs below follow the book, and the axes are all labelled as fractions of R, so the arithmetic works either way. But if you carry a number from here into another section, check the unit first.
Scenario 1 — two senders, and a router with infinite buffers
The simplest congestion possible. Hosts A and B each have a connection sharing a single hop, over a router whose outgoing link has capacity R and whose buffer is infinite.
The transport protocol is deliberately naive: encapsulate and send, with no error recovery, no flow control and no congestion control. Each host offers λ_in bytes per second of original data.
At 0.600 (move the pointer over the plot to read it anywhere):
- throughput λ_out:0.500
- average delay:—
Two graphs of the same situation. The left one says everything is fine; the right one says it is not. Both are true.
Two graphs, two verdicts, both correct
Throughput. Between 0 and R/2, everything sent arrives — throughput equals the sending rate. Above R/2 it stays at R/2, because two connections share one link of capacity R. No matter how hard either host pushes, neither will ever see more than R/2.
Delay. As the sending rate approaches R/2 from below, the average delay grows larger and larger. At R/2 and beyond, the number of queued packets is unbounded and the average delay becomes infinite.
So operating near capacity is ideal from a throughput standpoint — the link is fully used — and far from ideal from a delay standpoint. That is the first cost of congestion, and notice that it appears in a scenario where nothing goes wrong: no loss, no retransmission, no wasted work.
Traffic intensity La/R = (8,000 bits × 1400/s) ÷ 10 Mbps = 1.12 — above 1: the queue can only grow
- Arrived
- 0
- Sent on
- 0
- Dropped ✕
- 0 (0.0 %)
Section 1.4.2’s queue, revisited with congestion in mind. Push the arrival rate past the service rate and watch the drops — every one of them is a packet that consumed capacity upstream for nothing.
Scenario 2 — finite buffers, so packets are actually lost
Two changes make it realistic. The router’s buffer is finite, so packets arriving to a full buffer are dropped. And each connection is reliable: a dropped segment is eventually retransmitted.
That forces a distinction the rest of the section depends on:
- λ_in is the rate the application sends original data into the socket.
- λ′_in is the rate the transport layer sends segments — original and retransmitted — into the network. This is the offered load offered load Simple Everything a sender actually puts into the network, original data and retransmissions together. Precise λ′_in: the rate at which the transport layer sends segments into the network, counting both original data and retransmitted data. It is distinct from λ_in, the rate at which the application supplies original data, and from λ_out, the throughput measured at the receiver. Keeping the three apart is what makes the congestion scenarios of §3.6.1 readable. introduced in ch. 3 — open in glossary .
At 0.500 (move the pointer over the plot to read it anywhere):
- (a) magical sender — never loses anything:0.500
- (b) retransmits only what is really lost:0.333
- (c) also retransmits packets that were merely slow:0.250
Three senders of increasing realism, on the same axes. Read them right to left: the ideal, the honest, and the one that also times out too early.
Three senders, in order of honesty
(a) The magical sender. Suppose Host A could somehow know whether a buffer is free, and sent only when one was. No loss would occur, λ_in would equal λ′_in, and throughput would equal λ_in. Perfect — and impossible.
(b) The sender that retransmits only what is genuinely lost. Still a stretch, but at least imaginable: a host could set its timeout large enough to be virtually certain that an unacknowledged packet really was lost. At an offered load of R/2, throughput is R/3. Of that 0.5R, about 0.333R is original data and about 0.167R is retransmission.
(c) The sender that also times out too early. Now a packet that was merely delayed in the queue gets retransmitted. Both copies reach the receiver, which needs only one and discards the other. If each packet is forwarded on average twice, the asymptote falls from R/3 to R/4.
In plain words
Curve (b) is the second cost: you must retransmit to replace what was dropped, so a third of your effort goes on data the receiver has already been sent once.
Curve (c) is the third cost: your own impatience makes a router carry a copy nobody needed. The router’s link capacity would have been better used transmitting a different packet.
Scenario 3 — four senders, two hops each
The last scenario is where it stops being a matter of degree.
Four hosts, each sending over a two-hop path, and the paths overlap. The A–C connection passes through routers R1 and R2. It shares R1 with the D–B connection, and shares R2 with the B–D connection.
At 1.6 (move the pointer over the plot to read it anywhere):
- throughput λ_out of the A–C connection:0.003
The graph the whole section exists for. Push the offered load past the peak and watch what happens to the throughput.
Throughput does not level off. It falls.
Follow the A–C connection as everyone’s offered load grows.
Traffic from A to C arrives at R2 only after R1 has forwarded it. So its arrival rate at R2 can be at most R, the capacity of the R1-to-R2 link, however large λ_in becomes. But B–D traffic reaches R2 directly, and its arrival rate there can be far larger.
The two compete for R2’s finite buffer. As B–D’s offered load grows, the share of A–C traffic that survives R2 gets smaller and smaller. In the limit, an empty buffer at R2 is immediately filled by a B–D packet, and A–C’s throughput at R2 goes to zero.
In plain words — and this is the fourth cost
Every A–C packet dropped at R2 had already been carried across the first hop. That work is simply thrown away.
The book states the consequence in the sharpest possible form: the network would have been equally well off if the first router had discarded that packet and remained idle. The capacity R1 spent forwarding a packet that R2 was going to drop could have carried a packet that survived.
So: when a packet is dropped along a path, the transmission capacity used at every upstream link to carry it to the point where it died has been wasted. The further a packet gets before dying, the more it cost.
That is congestion collapse congestion collapse Simple The state where the network is busy but almost nothing useful arrives. Precise The condition in which increasing the offered load makes throughput fall rather than rise, because capacity is being spent on packets that will be dropped further along the path and on retransmissions of packets already delivered. In the limit of scenario 3, a connection’s end-to-end throughput approaches zero. Observed on the real Internet in the 1980s, which is what TCP congestion control was written to fix [Jacobson 1988]. introduced in ch. 3 — open in glossary , and it is not a theoretical curiosity — it happened on the real Internet in the 1980s, and section 3.7.1 exists because of it.
| The cost | Where it shows up | |
|---|---|---|
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
One per scenario, except scenario 2, which produces two. Each is worse than the one before it.
Two ways to control it
Congestion network congestion Simple Too many senders pushing data through the network faster than it can carry it. Precise The condition in which too many sources are sending too fast for the network to handle, so router queues grow and eventually overflow. Retransmission treats a symptom of congestion — a lost segment — but not the cause. Its costs are large queuing delays, retransmissions that would not otherwise be needed, and upstream capacity spent carrying packets that are dropped further along. introduced in ch. 3 — open in glossary has to be controlled somehow. At the highest level, the approaches divide on one question: does the network layer provide explicit assistance to the transport layer, or not?
| End-to-endno help from the network | Network-assistedrouters say so explicitly | |
|---|---|---|
| How the sender learns | ||
| The signal | ||
| Used by | ||
| What the router must do | ||
| How quickly the news arrives |
Cells marked ⓘ have a reason behind them — click to read it.
The dividing question is simple: does the network layer help, or not?
And if a router does want to say something, it has two routes
Direct feedback. The router sends a packet straight back to the sender. This is a choke packet choke packet Simple A message a router sends straight back to the sender saying "I am congested". Precise The direct form of network-assisted feedback: a router sends a packet to the sender to report congestion. The other and more common form marks a field in a packet already travelling towards the receiver, which then tells the sender — a route that costs a full round-trip time. ECN uses the second form. introduced in ch. 3 — open in glossary , and it says essentially “I’m congested!”. Fast, and it obliges the router to build and address a packet of its own.
Marking a passing packet. The router sets a field in a packet already travelling from sender to receiver. The receiver sees the mark and notifies the sender. This is the second and more common form — it costs the router almost nothing — but the news takes a full round-trip time to arrive.
Section 3.7.2’s Explicit Congestion Notification is the second kind, and it is exactly this: two bits in the 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 header, echoed back by the receiver in a TCP acknowledgement.
Note the trade the Internet made
End-to-end end-to-end congestion control Simple Working out that the network is congested from what the two ends can see, with no help from routers. Precise The approach in which the network layer gives the transport layer no explicit help, so congestion must be inferred from observed behaviour — lost segments, or rising delay. Classic TCP takes this approach: a timeout or three duplicate acknowledgements is read as a sign of congestion and the congestion window is reduced. introduced in ch. 3 — open in glossary control requires nothing whatsoever of the routers, which is why it could be deployed on an Internet that already existed and that nobody owns.
Network-assisted network-assisted congestion control Simple Routers telling the ends directly that they are congested. Precise The approach in which routers give explicit feedback about their congestion state. The feedback can be as small as a single bit, as in the early IBM SNA, DEC DECnet and ATM architectures, or as detailed as ATM ABR’s explicit rate. On the Internet it appears as Explicit Congestion Notification. introduced in ch. 3 — open in glossary control is better informed and can warn before loss occurs — but it needs every router on the path to take part.
Classic TCP took the end-to-end road. Section 3.7.1 shows what it costs to work with such a thin signal: the sender must cause the problem before it can detect it.
Check yourself
Check yourself
0 of 6 answered1.Retransmission already recovers lost segments. Why is congestion control needed as well?
2.predictIn scenario 1, both senders push their rate towards R/2 on a router with infinite buffers. What happens?
Look at both graphs, not just the throughput one.
3.predictScenario 2, case (b): the offered load is R/2 and throughput is R/3. What is the missing R/6 doing?
4.predictSwitch the plot to scenario 3 and push the offered load past the peak. Why does throughput FALL?
5.What distinguishes end-to-end from network-assisted congestion control?
6.A router marks a field in a packet travelling from sender to receiver, and the receiver then tells the sender. What does that cost compared with a choke packet?
What to remember
- Retransmission treats the symptom; congestion control treats the cause — too many sources sending too fast.
- Congestion has four costs. Delay grows without bound as the rate nears capacity, even with no loss. An offered load of R/2 delivers R/3, and premature timeouts drop that to R/4. Worst, capacity spent on a packet dropped further along is entirely wasted, so throughput falls as load rises.
- End-to-end control infers congestion from loss or delay and asks nothing of routers. Network-assisted control gets told, and asks a lot.