Safe Congestion Control

4.1. Free from congestion collapse

Adverse conditions do not cause increasing overhead, specifically do not cause duplicate data at the receiver.¶

Test: for a fixed work load, the overhead must be constant, independent of the network congestions across the entire operating range of the application or network¶

If there is packet loss, the retransmits must exactly match the losses.¶

Example of an application that can cause congestion collapse: an automatic download engine that responds to transient network errors or persistent congestion by restarting downloads from the beginning. For example git-clone can not be restarted mid transfer. Failures caused by extreme overload or transient outages require removing and re-cloning the destination.¶

Non-material example of congestion collapse: A download engine that properly restarts from where it left off still needs to repeat the connection establishment, ssl negotiation and other signaling, thus increases its overhead by a few bytes. If the payload is not tiny, this is generally non-material. If the payload is tiny and the relative overhead might be large, and might be prone to congestion collapse.¶

4.2. Free from regenerative congestion

Adverse conditions must not cause additional presented load. Any congestion indication should cause transmissions to be later than they would have been without the congestion.¶

This criteria is well understood at the transport layer: all congestion signals must cause the sender to delay future transmissions, and at least slightly reduce their average sending rate.¶

This criteria is not well understood by application designers. Many applications open multiple transport connections and use aggressive retry strategies with insufficiently adaptive timers (see Section 4.13). This flawed strategy is generally an attempt to maintain constant performance without reacting adverse network conditions.¶

Some (past?) streaming video application are known to request additional video chunks on alternate connections without regard to the delivery status of chunks already in progress. Such a strategy often yields better performance when the application is a minority of the traffic, but can cause massive regenerative congestion and eventual collapse in a large scale deployment.¶

4.3. Bound steady state losses

Steady state bulk transport should not cause more than 2% loss [study needed] over any unchanging network.¶

Any transport with some form of selective acknowledgements can easily operate at a much higher loss rate. The real problem is the harm that transport might cause to all single packet transactions, including DNS queries and connection establishment for nearly all protocols and services. Single packet transactions generally can only use an RTO timer for recovery, often without any preceding RTT measurement, thus they typically take several orders of magnitude more time than any selective acknowledgment based recovery built into a transport protocol.¶

The question at hand is really how much harm should we permit transport to inflict on all other protocols?¶

For example, are we ok with happy eyeballs [happyEyeballs] getting the wrong answer 2% of the time, because the IPv6 connection establishment failed on the first message?¶

[BTW I consider 2% to be a bit excessive: 1% or 0.1% would be better, however that may be unrealistically low. Reno and Cubic can both easily cause much higher loss rates. ]¶

[We need some studies to justify the appropriate value for the final document.]¶

4.4. Bound slowstart duration and loss

Slowstart into a droptail queue should not cause more than one RTT of loss nor cause more than 50% loss for that RTT. Provisional window or rate reductions should start promptly when losses or disorder is first detected, even before the loss recovery can decide if the missing segments are due to reordering or loss.¶

4.5. Bound losses on link changes

Step changes in link properties (RTT, bandwidth or queue size) or cross traffic should not cause losses that are larger than the change in maximum flight size supported by the link. Specifically, during loss recovery the transport is not permitted to send more data than the receiver reported as having been delivered. This is the strict Conservative property from Proportional Rate reduction.¶

4.6. No unnecessary slowstarts

All application stacks must use connection caching, Congestion Control state caching or some other mechanism such that application workloads are prevented from causing persistent or repeated overlapping slowstarts.¶

[RFC9040] TCP Control Block Interdependence¶

draft-kuhn-tsvwg-careful-resume-00 Careful convergence of congestion control from retained state with QUIC¶

4.7. Freedom from starvation

Flows below some resource threshold (data rate, window size, ConEx marks, etc) will successfully search upwards, as long as there is either idle capacity or other flows above the some threshold. To some extent the thresholds will depend on the path properties and other sources of noise.¶

@@@@ more work is needed here.¶

4.8. Bound standing queue

In the absence of losses or ECN, bulk flow should not cause steady state standing queues larger than k*minRTT*maxBW, for some predefined k, specific to the CCA. K must be smaller than 2 (maximum RTT would be 3*minRTT)¶

Note that this criteria implies that ECN based CCAs must also have some mechanism to limit data inflight, and that all CCAs must address the minimum RTT estimator problem described in Appendix A.¶

4.9. Bound control frequency

Control frequency scales with 1/rtt but is insensitive to data rate. This property is referred to as "scalable" in other sources.¶

[RFC9330] Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture¶

Robert Morris Scalable TCP Congestion Control¶

4.10. Maintain queue headroom

Individual flows do not persistently maintain full queues even if the queues are smaller than minRTT*maxBW. When there is queue full, Congestion Control should reduce its window enough to create some small headroom to prevent locking out new flows.¶

Ideally this criteria would also be applied to flow aggregates, however significant additional research would be needed. @@@@¶

4.11. Monotonic response

The CCA should have monotonic response to all congestion signals that it responds to (loss, marks, delay, etc) otherwise it will have multiple stable operating points for the same network conditions. It would be likely to exhibit stable pathologies such as latecomer (dis)advantage.¶

4.12. Balanced probe size

Balance the worst case queue backlog against the need to trigger mode shifting in links that use queue backlog as a trigger.¶

Self clock transport preserves ACK modulation from one RTT to the next. Many half duplex link layers implicitly use bursts preserved by transport self clock as part of optimizing their channel allocation algorithms. Batching or decimating ACKs on the return path can cause relatively large bursts of packets to traverse the entire forward path from the sender to the receiver, potentially causing jitter to other flows sharing the same queues.¶

Pacing can interact poorly with link layers that rely on queue backlogs to trigger transmissions or scheduling mode changes. These types of link scheduling algorithms are pervasive in wireless and other shared media where channel arbitration is relatively expensive. Indeed, the initial design of BBR's bandwidth probe phase was inspired by the need to trigger mode changes in many wireless networks.¶

@@@@ More work needed here.¶

4.13. Self scaling

All protocol layers must be self scaling. If the network is too slow, the application must also slow down to avoid "stacking" requests.¶

Specifically all application timers that cancel or restart lower layers transactions must not start overlapping transactions and must use an RTO style retry algorithm based on observed transaction times, including exponential backoff on repeated failures. Alternatively an application might refuse to run after excessive failures.¶

This criteria must be applied recursively all the way up the protocol stack for all applications that might be unattended (e.g. cron jobs and IOT devices).¶