Re: [tcpm] Errata RFC9438 (Cubic)

[Vidhi Goel <[e-mail]>]

Hi Richard,

> The stack I'm familiar with does CC processing first (with the old value
> for snd_una, not yet updated by th_ack, and flight size is the expected
> value of 10 mss at that moment...

For the case that Yoshi described, once the ACK arrives, the flight size is 0. Also, we don’t control when the different implementations update their snd_una.

Regarding using flightsize vs cwnd, we had a long discussion about this before. We tried to make sure that we are not getting cornered by using very low flight size (in some scenarios) as well as we are not setting ssthresh to a high value for app limited cases. Please see https://datatracker.ietf.org/doc/html/rfc9438#name-multiplicative-decrease

Let me know if that section is not clear.

Vidhi



> On Feb 10, 2024, at 5:23 AM, rs.ietf=[e-mail] wrote:
> 
> 
> Hi Yoshi,
> 
> Well, that probably comes down to the order in which snd_una is updated
> vs. ssthresh being set - and at what stage Flight Size is calculated
> during the processing of the incoming packet.
> 
> If th_ack is first updating snd_una, then the flight size calculation
> would probably end up with the incorrect, deflated value.
> 
> The stack I'm familiar with does CC processing first (with the old value
> for snd_una, not yet updated by th_ack, and flight size is the expected
> value of 10 mss at that moment...
> 
> Capturing all that nuance would need more text; I believe the critical
> aspect is to no blindly use cwnd, when adjusting ssthresh, since that
> may not reflect the (expected) flight size under all circumstances, e.g.
> RTO during the initial Fast Retransmission...
> 
> Hope that makes sense.
> 
> Best regards,
>  Richard
> 
> 
> 
> 
> Am 10.02.2024 um 12:53 schrieb Yoshifumi Nishida:
>> Hi Richard,
>> 
>> I am wondering about cases like this.
>> Say a sender sends 10 packets (cwnd=10) during slow-start and the
>> receiver sends back a single ack that acknowledges all packets.
>> Then,  hystart or hystart++ at the sender decides to exit slow-starts
>> from the RTT and set ssthresh.
>> I think flighsize will be 0 in this situation, but would it be OK?
>> --
>> Yoshi
>> 
>> 
>> On Fri, Feb 9, 2024 at 8:23 AM Scheffenegger, Richard
>> <rs.ietf=[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>    Hi,
>> 
>>    Lately I've been looking at the TCP behavior when multiple events
>>    overlap (e.g. RTO while loss recovery is not complete; or duplicate ACKs
>>    immediately after RTO before snd_nxt reaches snd_max again).
>> 
>>    I believe there is an implicit assumption in the Cubic RFC around
>>    cwnd_prior to track Flight Size - which does not always hold (but
>>    depends also on the specific implementation).
>> 
>>    RFC5681 is quite clear, that ssthresh is to be adjusted after an RTO,
>>    not by taking cwnd, but rather the FlightSize.
>> 
>>    The wording in RFC9438 appears to overrule this (as it updates RFC5681)
>>    and reverts back to how ssthresh got set prior to RFC5681, using cwnd
>>    directly again.
>> 
>> 
>>    As mentioned, cwnd does not always reliably track Flight Size (in
>>    particular, early on after initiating Loss Recovery, it may only be 1
>>    MSS). If an RTO happens and the text in RFC9438 is followed verbatim,
>>    ssthresh may end up being updated to cwnd * beta_cubic (0.7), instead of
>>    the Flight Size at this stage of Loss Recovery...
>> 
>> 
>>    I hope the errata, to clear up that the RFC5681 guidance as how to
>>    adjust ssthresh on an RTO based on Flight Size, not cwnd, is found
>>    useful - since it appears to me that this was clearly the intent.
>> 
>>    Best regards,
>>        Richard
>> 
>>    _______________________________________________
>>    tcpm mailing list
>>    [e-mail] <mailto:[e-mail]>
>>    https://www.ietf.org/mailman/listinfo/tcpm
>>    <https://www.ietf.org/mailman/listinfo/tcpm>
>> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm