Found 1 record.
Status: Reported (1)
RFC 9438, "CUBIC for Fast and Long-Distance Networks", August 2023Source of RFC: tcpm (tsv)
Errata ID: 7806
Publication Format(s) : TEXT, PDF, HTML
Reported By: Richard Scheffenegger
Date Reported: 2024-02-09
Section 4.1.2 says:
* cwndprior: Size of cwnd in segments at the time of setting ssthresh most recently, either upon exiting the first slow start or just before cwnd was reduced in the last congestion event.
It should say:
* cwndprior: Flight Size as defined in RFC5681 in segments at the time of setting ssthresh most recently, either upon exiting the first slow start or just before cwnd was reduced in the last congestion event.
The implicit assumption appears to be, that only singular, isolated events happen during a cubic congestion control response. However, it is not uncommon that multiple events, such as loss, loss recovery initiation, followed by one or more RTOs happen. In many implementations, cwnd only properly tracks Flight Size while no loss recovery is going on. RFC5681 made it clear, that adjustments to ssthresh should be based off of the (estimated) Flightsize. Similarly, it appears prudent to observe Flight Size and not a potentially adjusted cwnd value here.
The observed effect of deriving cwnd_prior directly from cwnd, and not Flight Size is a deflated value for ssthresh, earlier transition from slow-start to congestion avoidance, and less rapid resumption of reasonable bandwidth after e.g. a burst loss event followed by a RTO.
RFC5681 section 7 has this to say around setting ssthresh:
The treatment of ssthresh on retransmission timeout was clarified.
In particular, ssthresh must be set to half the FlightSize on the
first retransmission of a given segment and then is held constant on
subsequent retransmissions of the same segment.