Slow Start
There is no field anywhere in TCP for how fast you may send. No router tells you, and the only thing the network ever reports is that something was lost, which arrives a round trip after the damage. So the sender finds out by pushing until it hurts. Slow start is not slow: doubling every round trip is the fastest safe thing to do when you know nothing at all.
Doubling, loss, collapse, and climbing back a segment at a time
1 One segment, then two, then four
The window is how much may be in flight at once. It opens at one segment and doubles every round trip, so it reaches a thousand in ten of them rather than a thousand.
| rtt | window | sent | arrived | phase |
|---|---|---|---|---|
| 1 | 1 | 1 | 1 | slow start |
| 2 | 2 | 2 | 2 | slow start |
| 3 | 4 | 4 | 4 | slow start |
| 4 | 8 | 8 | 8 | slow start |
| 5 | 16 | 16 | 16 | slow start |
| 6 | 32 | 32 | 24 | lost a segment |
| 7 | 1 | 1 | 1 | slow start |
| 8 | 2 | 2 | 2 | slow start |
| 9 | 4 | 4 | 4 | slow start |
| 10 | 8 | 8 | 8 | slow start |
| 11 | 16 | 16 | 16 | congestion avoidance |
| 12 | 17 | 17 | 17 | congestion avoidance |
| 13 | 18 | 18 | 18 | congestion avoidance |
| 14 | 19 | 19 | 19 | congestion avoidance |
| 15 | 20 | 20 | 20 | congestion avoidance |
| 16 | 21 | 21 | 21 | congestion avoidance |
| 17 | 22 | 22 | 22 | congestion avoidance |
| 18 | 23 | 23 | 23 | congestion avoidance |
| 19 | 24 | 24 | 24 | congestion avoidance |
| 20 | 25 | 25 | 24 | lost a segment |
2 The window growing until something is dropped
Nothing announces the limit. The window keeps doubling straight past what the path can carry, and the first the sender knows of it is a segment that does not arrive.
- the widest the window got
- 32 segments
- the round trip that first lost something
- round trip 6
3 Loss, which is the only signal the network ever sends back
Loss is the entire feedback channel. Not a rate, not a warning, not a number: one bit of information, arriving a round trip late, meaning you have already gone too far.
- round trips that lost a segment
- 2
- where it now stops doubling
- 16 segments
4 Back off, and probe again from there
So it halves what it believes the limit is, restarts at one segment, and doubles back up to that belief before switching to one extra segment per round trip. The sawtooth in the table above is the shape of never being told.
- segments delivered
- 274
- what a sender who knew would have carried
- 480
- efficiency
- 57 per cent
Over 20 round trips this carried 274 segments where a sender who simply knew the answer would have carried 480. The missing 43 per cent is the cost of there being nothing in the protocol that tells you, and of the only signal arriving a round trip after it was needed.
What is real here, and what is not
This is the 1988 behaviour, and TCP has not stood still
A loss here halves the threshold and drops the window to one, which is the original algorithm and is brutal. Fast retransmit and fast recovery, added within a few years, let a sender that loses one segment keep going at half rate instead of starting over. Modern stacks start at ten segments rather than one, and several no longer treat loss as the only signal at all.
The path is a single number and real ones are not
One capacity, constant for the whole run, and a loss exactly when the window exceeds it. A real path shares a queue with everybody else's traffic, its capacity moves, and loss can happen for reasons that have nothing to do with congestion, which is exactly why treating loss as congestion goes wrong on a lossy wireless link.
Round trips are the clock here, and time is not modelled
Everything is counted in round trips rather than seconds, because that is the unit the algorithm actually works in. It does mean the page cannot show the thing that makes slow start painful in practice, which is that a short connection may finish before the window ever opens.