Skip to main content

8. Examples

This section illustrates the behavior of the PRR and [RFC6675] algorithms by showing how they differ in their response to two example scenarios: a connection experiencing a single lost packet or a burst of 15 consecutive lost packets.

Test Scenario Setup​

All cases use:

  • Bulk data transfer (no application pauses)
  • Reno congestion control [RFC5681]
  • Initial state: cwnd = FlightSize = inflight = 20 segments
  • ssthresh: Will be set to 10 at the beginning of recovery
  • Fast retransmit: Uses standard fast retransmit [RFC5681]
  • Limited Transmit [RFC3042]: Sends 2 new segments + 1 retransmission in response to the first three duplicate ACKs

Diagram Explanation​

The following diagrams show the per-ACK response for the first round trip after the loss of segment 0. The top row ("ack#") indicates the segment number that triggered the ACK, with X indicating lost segments.

The "cwnd" and "inflight" rows show the values of these algorithms' cwnd and inflight after processing each returning ACK but before any further (re)transmissions. The "sent" row indicates how many "N" new data or "R" retransmissions will be sent.

Example 1: Single Segment Loss​

RFC 6675
a  X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
i 19 19 18 18 17 16 15 14 13 12 11 10  9  9  9  9  9  9  9  9  9  9
s  N  N  R  N  N  N  N  N  N  N  N  N  N

PRR
a  X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 10
i 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10  9  9
s  N  N  R  N  N  N  N  N  N  N  N  N  N

a: ack#; c: cwnd; i: inflight; s: sent

Analysis​

In this first example:

ACK Sequence:

  • ACKs #1 through #19 carry SACKs of the original flight of data
  • ACKs #20 and #21 carry SACKs for the two segments triggered by limited transmit
  • ACK #22 carries a full cumulative ACK covering all data (including limited transmit)
  • ACK #22 completes fast recovery phase, thus completing the PRR phase

Behavior Comparison:

  • Both algorithms send the same total amount of data
  • Both finish fast recovery with cwnd matching ssthresh at a value of 20
  • RFC 6675 experiences a "half-window of silence"
  • PRR spreads voluntary window reductions across the entire RTT

Example 2: Burst Loss of 15 Segments​

Next, consider the example scenario with the same initial conditions, except that the first 15 packets (0-14) are lost. During the remainder of the lossy RTT, only 5 ACKs are returned to the sender. Each algorithm is examined in sequence below.

RFC 6675
a  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
c 20 20 10 10 10
i 19 19  4  9  9
s  N  N  6R  R  R

PRR
a  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
c 20 20  5  5  5
i 19 19  4  4  4
s  N  N  R  R  R

a: ack#; c: cwnd; i: inflight; s: sent

Analysis​

In this particular case:

RFC 6675 Behavior:

  • Once fast retransmit is triggered (on the ACK of segment 17), the sender immediately retransmits enough data for inflight to rise to match cwnd
  • Early measurements (discussed in Section 6 of [RFC6675]) show that [RFC6675] significantly outperforms the [RFC6937] version of PRR (which used only PRR-CRB) and other tested similarly conservative algorithms
  • It demonstrates that situations where the actual losses exceed the cwnd reduction determined by the congestion control algorithm are very common

PRR Behavior:

  • During the first RTT of fast recovery, PRR follows packet conservation using PRR-CRB
  • Since total losses keep inflight below ssthresh, the data sent makes the total transmitted data prr_out follow the total data reported by returning ACKs as delivered to the receiver
  • Transmissions are controlled by the sending limit, set to prr_delivered - prr_out

Recovery Process:

  • Although not shown in the diagram, once the fast retransmissions sent starting at ACK #17 are delivered and cause ACKs that increase SND.UNA, PRR enters PRR-SSRB
  • Increases the window by exactly 1 segment per ACK during recovery until inflight rises to ssthresh during recovery
  • For severe losses when cwnd is large, PRR-SSRB recovers exponentially faster than PRR-CRB
  • While it may seem unwise to increase the window during recovery, it's important to remember this is actually more conservative than what [RFC6675] allows, which sends the same amount of additional data as a single burst in response to the ACK that triggered fast retransmit

Mild Loss Cases: For less severe loss events where total losses are less than the difference between FlightSize and ssthresh, PRR-CRB and PRR-SSRB are not invoked because PRR remains in proportional rate reduction mode.

Last updated on