[tcpm] Re: About growing cwnd when the sender is rate-limited

[Michael Welzl <[e-mail]>]

Absolutely, yes - the draft is targeting ccwg for that reason. Sorry for starting this here, and thanks for the note!  I’ll follow up with an email to ccwg to avoid cross-posting.
Let this be the latest message of that thread to TCPM.

Cheers,
Michael



> On Jul 20, 2024, at 9:10 PM, Christian Huitema <[e-mail]> wrote:
> 
> 
> Should we not have this discussion in CCWG? The "sender limited" scenario is an issue with multiple transports, not just TCP.
> 
> -- Christian Huitema
> 
> 
> 
> On 7/20/2024 3:05 PM, Michael Welzl wrote:
>> Hi !
>> Now, I can finally answer the third rationale - sorry for the interruption. In short, I don’t agree:
>>> Rationale 3: justifying acceleration in the convex region of CA
>>> ----------------
>>> 
>>> With the most widely deployed CC on the Internet, CUBIC, part of the rationale for the accelerating growth of cwnd in the convex region of congestion avoidance is: with cwnd above W_max, the longer a flow has proceeded in accelerating its sending rate without experiencing loss, the more confident we are that it is safe to grow cwnd with increasingly large increments. But AFAICT that rationale only makes sense if the cwnd is fully utilized, i.e., if the sender is actually accelerating.
>> How is that rationale different from the rationale behind slow start? We’re in a state which is in some sense unexpected - something has happened: a routing change, many flows leaving, …  and so we probe “into the unknown”.  To me, this is quite the same.
>>> For example, if we imagine a cwnd growing in a convex fashion (qualitatively similar to CUBIC) above W_max = 1,000 MSS, and if we imagine we use an approach like draft-welzl-ccwg-ratelimited-increase-02, and don't check whether cwnd is fully utilized, but allow cwnd to grow to 2x the max FlightSize, then we get an implict rationale of the flavor:
>>> 
>>> [round #] : [FlightSize sent, CC decision for cwnd]
>>> -------------------------------------------------------
>>>  1: FlightSize = 1,000 MSS worked, cwnd = 1,001 is fine
>>>  2: FlightSize = 1,000 MSS worked, cwnd = 1,002 is fine
>>>  3: FlightSize = 1,000 MSS worked, cwnd = 1,005 is fine
>>>  4: FlightSize = 1,000 MSS worked, cwnd = 1,010 is fine
>>>  5: FlightSize = 1,000 MSS worked, cwnd = 1,020 is fine
>>>  6: FlightSize = 1,000 MSS worked, cwnd = 1,050 is fine
>>>  7: FlightSize = 1,000 MSS worked, cwnd = 1,125 is fine
>>>  8: FlightSize = 1,000 MSS worked, cwnd = 1,250 is fine
>>>  9: FlightSize = 1,000 MSS worked, cwnd = 1,500 is fine
>>> 10: FlightSize = 1,000 MSS worked, cwnd = 2,000 is fine
>>> 
>>> (CUBIC grows more slowly than that, but this is the qualitative behavior. And AFAICT the argument holds for any CC with some phase of convex cwnd growth. BBRv2 / BBRv3 have qualitatively similar behavior in this regard.)
>>> 
>>> IMHO that behavior does not make sense, or at least seems needlessly risky:
>>> 
>>> (a) Why would a congestion control algorithm deem that it can safely accelerate its growth of cwnd above W_max = 1,000 in this way if FlightSize never gets above 1,000 packets?
>> Congestion control works upon the state that it has seen (and contributed to) during the last RTT. Anything that happens after this RTT doesn’t affect that state.
>> So, in your example above: we have sent 1,000 MSS, and as with slow start, we deem it appropriate to double cwnd within an RTT. If FlightSize has increased from round 1 to 10 (here, I presume, a round is a cwnd update upon an ACK arrival) or if it hasn’t increased at all, i.e. how much the sender has sent in response to these ACKs, is unsubstantial for this decision. With a slow start like increase, by the time we have reached cwnd = 2,000, we haven’t received any ACKs that could tell us anything about how the packets that were sent or not sent after round #1 have influenced the network.
>>> (b) What is the expected level of loss in this scenario if the flow transitions back to fully utilizing its cwnd? If the "safe" (no-loss) FlightSize really is still 1,000 MSS, then the expected loss rate in this case when fully using this cwnd and sending 2,000 MSS is a 50% packet loss rate (1,000 MSS lost out of 2,000 MSS sent).
>> Yes, 50%, as with slow start. That’s just because we double, it has nothing to do with whether we have sent more packets during that RTT or not.
>>> ----------------
>>> 
>>> That said, I agree that it's worth further discussion of, and possibly experiments with, approaches more like draft-welzl-ccwg-ratelimited-increase-02, allowing cwnd to grow to 2 * max_packets_out in any state. Partly because it's easy to come up with theoretical arguments (like mine above) for why a CC approach is too aggressive, and sometimes aggressive approaches work surprisingly well in practice (I am thinking here of slow start...).
>> We’re not proposing an experiment, we aim for PS. The arguments are:
>> * If you dislike our specific “can increase, also in Congestion Avoidance, as the congestion control algorithm would normally do” rule, then that’s fine, because this rule is classified as SHOULD. The MUST only says: "MUST include a limit to the growth of cwnd when FlightSize < cwnd.”  I think it’s hard to disagree with this specific statement? Limit it somehow, don’t allow to increase endlessly  (as, e.g., ns-3 does, and perhaps Linux would also do in CA, I don’t know).  Look at slide 2 here:
>> https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-slides-for-draft-welzl-ccwg-ratelimited-increase-01
>> =>  my point is, it should be hard to disagree with: “such an endless yet meaningless increase is terrible and should never happen”.
>> * in one way or another, most implementations do something along these lines anyway, and specs say something along these lines too, but it’s all rather messy. We’re trying to clean this up.
>> * I do think that our specific increase rule (the "SHOULD") just cleans up an oddity in the cc specs, it’s not really a “more aggressive” CC approach. Instead, I would argue that stopping to increase would seem like a departure from normal congestion control behavior: cc. algorithms measure the past RTT and react upon it - but by disallowing to increase for one RTT, all of a sudden, an event whose impact has not yet been measured would influence what the CC algorithm does. That just seems wrong. You can surely find situations where Cubic’s convex increase in general plays out badly, or where slow start is too aggressive, but that’s just the algorithms behavior. Whether we have sent new packets or not should be unsubstantial for the algorithm’s decision for one RTT (which is what we automatically get from maxFS).
>> I hope this clears it up a little bit?
>> Cheers,
>> Michael
>> _______________________________________________
>> tcpm mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]