4. Changes Relative to RFC 6937

The largest change since [RFC6937] is the introduction of a new heuristic that uses good recovery progress (for TCP, when the latest ACK advances SND.UNA and does not indicate that a previous fast retransmit was lost) to select the reduction bound (PRR-CRB or PRR-SSRB).

[RFC6937] left the choice of reduction bound to the implementer's discretion but recommended using PRR-SSRB as the default. For all of the environments explored in the earlier PRR research, the new heuristic is consistent with the old recommendation.

Introduction of the SafeACK Heuristic

The paper "Internet-Wide Analysis of Traffic Policing" [Flach2016policing] discovered a previously unexplored critical case where both reduction bounds perform poorly, but for different reasons.

Challenge of Token Bucket Policers

In many configurations, token bucket traffic policers can abruptly start dropping most traffic when tokens are exhausted, without any warning to the end systems. Transport congestion control has no opportunity to measure the token rate and set ssthresh based on previously observed path performance. This ssthresh value can lead to a data rate far greater than the token replenishment rate, resulting in high packet loss rates.

Under these conditions, both reduction bounds perform poorly:

• PRR-CRB is too conservative - sometimes resulting in very long recovery at a much smaller window than necessary
• PRR-SSRB is too aggressive - often resulting in multiple rounds of lost retransmissions, both cases resulting in prolonged recovery times that severely impact application latency and/or throughput

SafeACK Solution

Investigation of these environments led to the development of the "SafeACK" heuristic to dynamically switch the reduction bound:

• Default to PRR-CRB - start recovery conservatively
• Switch to PRR-SSRB condition - only when an ACK indicates recovery is progressing well (SND.UNA advances and no new packet loss detected)

The SafeACK heuristic was experimented with at Google's content distribution network (CDN) [Flach2016policing] and has been implemented in Linux TCP since 2015.

Application Scenarios

The SafeACK heuristic is only invoked when:

• Packet loss, application-limited behavior, or other events cause the current inflight data estimate to fall below ssthresh
• High packet loss rates make the heuristic critical, which is only common in the presence of severe packet loss, such as traffic policers [Flach2016policing]
• In these environments, the heuristic outperforms using either bound alone