Re: [tcpm] Errata RFC9438 (Cubic)

[Richard Scheffenegger <[e-mail]>]

Thanks Vidhi,

Now that you point my nose into this, its clear - don't know why I
wasn't able to properly read this before; clearly some of the code I've
been looking at is incorrect here.

Best regards,
   Richard


Am 22.02.2024 um 21:10 schrieb Vidhi Goel:
> 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 <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
>