Re: [tcpm] Errata RFC9438 (Cubic)

["Rodney W. Grimes" <[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.

If one person implemented it wrong, and a second person trying to
understand it and see that it was implemented correctly both failed
at getting to the correct solution by reading the RFC that is to
specify these operations I would conclude "The RFC is flawed.".

Having to ask on a list for clarity, for me, indicates the RFC could
probably use some improvements.  This is not he first time I have
seen a thread similiar to this one on various topics in tsvwg and
tcpm.

> 
> 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
> >
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 

-- 
Rod Grimes                                                 [e-mail]