4.3.22 · D4Computer Networks

Exercises — TCP congestion control — slow start, congestion avoidance, fast retransmit, CUBIC

3,231 words15 min readBack to topic

Throughout, cwnd is measured in MSS (Maximum Segment Size = one segment).


Level 1 — Recognition

Problem 1.1

A TCP sender is in a phase where cwnd goes over four RTTs. Name the phase and state the growth type (exponential / linear).

Recall Solution 1.1

WHAT: cwnd doubles every RTT. Phase: Slow Start. Growth type: exponential (factor 2 per RTT). WHY it doubles: let = the current value of cwnd measured in segments. In one RTT the sender emits segments and (no loss) gets ACKs back; each ACK adds , so . This is the steep left (magenta) edge of the sawtooth in Figure s01 and the curving ramp in Figure s02.

Problem 1.2

Which of these is never transmitted in a TCP header: rwnd or cwnd? Explain in one line.

Recall Solution 1.2

cwnd is never on the wire — it is a local variable the sender keeps to protect the network's queues. rwnd is advertised in every ACK to protect the receiver's buffer. See Flow Control vs Congestion Control.

Problem 1.3

A sender receives three duplicate ACKs. Is this a severe or a mild congestion signal? Which mechanism fires?

Recall Solution 1.3

Mild. Later packets are still arriving (that's what generates the duplicates), so only one segment is lost. Mechanism: Fast Retransmit (resend immediately), followed by Fast Recovery (halve, stay in CA).


Level 2 — Application

Problem 2.1

MSS segment, cwnd starts at , ssthresh . List cwnd at the start of each RTT until CA begins.

Recall Solution 2.1

WHY doubling: let = the current cwnd in segments. In slow start every ACK adds , and one RTT with cwnd brings back ACKs, so each RTT (see Problem 1.1). We apply that rule until cwnd reaches the ssthresh border line (): At RTT4 cwnd reaches ssthresh ⇒ switch to CA. So the SS sequence is over RTT0…RTT4, then CA continues On Figure s01 this is the exponential ramp meeting the dashed ssthresh line; on Figure s02 it is the curving magenta ramp.

Problem 2.2

cwnd MSS when a timeout occurs. Give the new ssthresh, the new cwnd, and the next phase.

Recall Solution 2.2

Timeout rule:

  • MSS
  • Next phase: Slow Start (double , then reach and enter CA).

Problem 2.3

cwnd MSS when 3 duplicate ACKs arrive (Reno). Give new ssthresh, new cwnd, next phase. Compare with 2.2.

Recall Solution 2.3

Fast Recovery rule:

  • MSS
  • Next phase: Congestion Avoidance (linear MSS per RTT).

Compare: same ssthresh () as the timeout case, but cwnd falls only to (not ), and we skip slow start. WHY: milder signal ⇒ milder reaction — this is the whole point of matching reaction to severity (AIMD Fairness).

Problem 2.4

CUBIC with MSS, , . Compute (a) the window right after the loss, and (b) .

Recall Solution 2.4

(a) After a CUBIC loss the window drops by factor : (A real kernel floors this to MSS; we keep to show the rule.) (b) Check: at (recall = seconds since loss), ✓ (it climbs back exactly to the old peak).


Level 3 — Analysis

Problem 3.1

Two hosts share one link. Flow A has RTT ms, flow B has RTT ms, both in CA (Reno). After 1 second with no loss, how many MSS has each flow's cwnd grown by? Which flow is starved, and what property of CUBIC fixes this?

Recall Solution 3.1

WHAT: CA adds MSS per RTT.

  • Flow A: RTTs ⇒ MSS.
  • Flow B: RTTs ⇒ MSS.

Analysis: the short-RTT flow A grabs bandwidth faster — this is RTT unfairness. Reno's growth is tied to RTT, so low-RTT flows dominate. CUBIC's fix: depends on wall-clock seconds since loss (that again), not RTTs, so two flows with different RTTs climb at comparable real-time rates ⇒ better RTT fairness.

Problem 3.2

Explain why exactly 3 duplicate ACKs (not 1, not 2) triggers Fast Retransmit. What real event does the "3" defend against?

Recall Solution 3.2

TCP ACKs are cumulative: "I have everything up to byte X." If segment 5 is lost but 6,7,8 arrive, the receiver re-ACKs "I still want 5" each time.

  • 1 or 2 duplicates can happen from harmless packet reordering (segment 5 just took a slower path and hasn't arrived yet).
  • 3 duplicates is strong statistical evidence segment 5 is truly lost, not merely late.

So "3" is a noise threshold trading off false alarms (retransmitting a reordered-but-fine packet) against waiting too long. Retransmitting on the 3rd saves a whole RTO. See TCP Reliable Data Transfer.

Problem 3.3

On a long fat network (LFN) with bandwidth-delay product MSS, a Reno flow loses a packet at cwnd and halves to . How many RTTs to refill to ? If RTT ms, how long is that in seconds? One sentence on why CUBIC helps.

Recall Solution 3.3

WHAT: CA adds /RTT, so refilling MSS needs RTTs. Time: minutes — the pipe sits half-empty for minutes. Why CUBIC: its convex exploration phase () accelerates upward instead of crawling /RTT, refilling huge windows in seconds, not minutes.


Level 4 — Synthesis

Problem 4.1

Trace a full Reno session. MSS , cwnd starts , ssthresh starts . Events by RTT:

  • RTTs 0–3: normal growth.
  • At the start of RTT 4 cwnd would be some value; then a 3-dup-ACK loss occurs.
  • Continue normal growth after recovery.

Give cwnd at the start of RTTs 0 through 7 (eight values), and ssthresh after the loss.

Recall Solution 4.1

Slow start (cwnd ssthresh ), doubling:

  • RTT0: , RTT1: , RTT2: , RTT3: .

At RTT3 cwnd ssthresh ⇒ enter CA. So at start of RTT4 cwnd . Now the 3-dup-ACK loss hits at cwnd :

  • (a real kernel floors this to ; we keep to show the rule).
  • , stay in CA.

Post-recovery CA, MSS per RTT:

  • RTT5:
  • RTT6:

Full trace, cwnd at start of RTT0 … RTT7 (eight values): ssthresh after loss . WHY each step: exponential while below ssthresh, linear at/above it, halve-and-stay-CA on the mild dup-ACK loss — exactly the sawtooth of Figure s01.

Problem 4.2

Same as 4.1, but the loss at cwnd is a timeout instead. Give cwnd at start of RTTs 4 through 9.

Recall Solution 4.2

Timeout at cwnd :

  • , go to slow start.

Slow start doubles until cwnd reaches ssthresh , then switch to CA:

  • RTT4: cwnd (right after timeout)
  • RTT5:
  • RTT6:
  • RTT7: (reached ssthresh ⇒ CA)
  • RTT8: (CA, )
  • RTT9:

Compare with 4.1: identical ssthresh (), but the timeout forces cwnd all the way to and a fresh slow-start climb — a far deeper cut for the more severe signal. (Integer-flooring kernels would use ssthresh ; the shape is unchanged.)

Problem 4.3

A flow's throughput is . With MSS bytes and RTT ms, what cwnd (in MSS) is needed to sustain 240 Mbps? (Use bits/s.)

Recall Solution 4.3

Target rate bits/s bytes/s (÷8). Bytes per RTT we must have in flight bytes. In MSS: MSS. Meaning: this is exactly the bandwidth-delay product in segments — the window needed to keep the pipe full.


Level 5 — Mastery

Problem 5.1 (Derive)

Show from first principles that the CA per-ACK update yields exactly MSS per RTT.

Recall Solution 5.1

Setup: let = cwnd measured in MSS. In one RTT the sender emits segments and (no loss) receives ACKs. Per ACK increment (in bytes): . Sum over the ACKs in one RTT: So cwnd grows by exactly MSS per RTT — the Additive Increase of AIMD.

Problem 5.2 (Derive )

Derive CUBIC's from the requirement that the cubic passes through the post-loss window at and reaches at .

Recall Solution 5.2

Requirement 1 (at the peak): ✓ automatically — is where the curve tops out. Requirement 2 (at loss, ): the window just after loss is . Set: Meaning: is the real-time delay (in seconds) before CUBIC re-tests its old ceiling — the "memory" of where it broke.

Problem 5.3 (Analyse the cubic shape)

For , , (so s), compute at s. Classify each region as concave (cautious probing) or convex (exploring), and confirm the values against Figure s03.

Recall Solution 5.3

(here = seconds since the last loss).

  • : ← equals ✓.
  • : .
  • : ← the plateau at .
  • : .

What to observe in Figure s03: the magenta part of the curve () is concave — it shoots up out of then bends over and eases toward the dashed line: TCP is cautious as it re-approaches the value that broke it. The curve just kisses the plateau at (the violet dot). The orange part () is convex — it curls upward and accelerates past : now TCP probes for brand-new bandwidth. The four square markers are exactly the values you computed — check each sits on the curve.

Figure — TCP congestion control — slow start, congestion avoidance, fast retransmit, CUBIC

Problem 5.4 (Synthesis / design)

A designer wants CUBIC to behave more aggressively on LFNs by re-reaching faster (smaller ), holding , . Should they increase or decrease ? If they want halved from , find the required .

Recall Solution 5.4

From : increasing decreases (C is in the denominator). So to reach the peak faster, increase . Halving : , so requires Check: ✓. Trade-off caveat: larger is more aggressive ⇒ risks unfairness to gentler flows and can starve alternatives like BBR Congestion Control; production CUBIC keeps for a reason.


Recall Self-check summary

Which loss signal restarts slow start from cwnd = 1? ::: Timeout (RTO) — the severe signal. Which loss signal halves cwnd and stays in CA? ::: Three duplicate ACKs (Fast Recovery). What is ssthresh? ::: The border cwnd value separating slow start (below) from congestion avoidance (at/above); reset to cwnd/2 on every loss. What does RTT mean? ::: Round-trip time — one there-and-back of a segment plus its ACK; our natural clock tick. Is CUBIC's measured in RTTs or seconds? ::: Wall-clock seconds since the last loss. What is physically? ::: Time (in seconds) to climb back to the previous peak . Why increase by to halve ? ::: Because (cube-root dependence).