Re: [tcpm] Linux doesn’t implement RFC3465

[Yuchung Cheng <[e-mail]>]

The fact is that Linux CC has long moved to infinite L since 2013*

On Mon, Aug 2, 2021 at 11:03 AM Mark Allman <[e-mail]> wrote:

>
> >  “This document RECOMMENDS using mechanisms like Pacing to control
> >  how many bytes are sent to the network at a point of time. But if
> >  it is not possible to implement pacing, an implementation MAY
> >  implicitly pace their traffic by applying a limit L to the
> >  increase in congestion window per ACK during slow start. In
> >  modern stacks, acknowledgments are aggregated for various reason,
> >  CPU optimization, reducing network load etc. Hence it is common
> >  for a sender to receive an aggregated ACK that acknowledges more
> >  than 2 segments. For example, a stack that implements GRO could
> >  aggregate packets up to 64Kbytes or ~44 segments before passing
> >  on to the TCP layer and this would result in a single ACK to be
> >  generated by the TCP stack. Given that an initial window of 10
> >  packets in current deployments has been working fine, the draft
> >  makes a recommendation to set L=10 during slow start. This would
> >  mean that with every ACK, we are probing for a new capacity by
> >  sending 10 packets in addition to the previously discovered
> >  capacity. Implementations MAY choose to set a lower limit if they
> >  believe an increase of 10 is too aggressive."
> >
> > Does this sound like what we would like to say?
>
> Not really, IMO.  I think a few things here ...
>
>   - I agree that if pacing is in play that we don't need to worry
>     about an L.
>
>   - I think the above L=10 reasoning is at best pretty weak.  Just
>     because IW=10 works OK once / connection does not mean
>     continually sending "10 more" will work out OK.  It may.  It may
>     not.  But, the above sort of coupling between IW-10 and L=10
>     seems highly tenuous without any sort of data.
>
>   - The real issue with picking a number is that it is so hard to
>     reason about because the behavior All Depends.  E.g., consider
>     something like IW=10.  We know that will allow 10 or fewer
>     segments to be pumped into the network when the connection
>     starts.  That's pretty easy to reason about / understand.  But,
>     with L=10 we might have bursts anywhere from 2 packets to
>     cwnd+10 packets on every ACK---depending on how the ACKs are
>     stretched.  And, cwnd isn't a constant.  So, if the idea is to
>     somehow limit bursting then sometimes we're limiting to X and
>     others to Y and still others to Z.  It's an inconsistent mess.
>     Making L something arbitrary without evidence seems like a bad
>     path to me.
>
>   - Of course, by making L=10 a MAY we're effectively saying "no L,
>     anywhere" anyways.  If we're going to define an L it should be a
>     SHOULD unless there is pacing.
>
>   - Somewhat related to the above, it isn't clear what "10 more" is
>     more than in qualitative terms, as well.  Say an ACK rolls in
>     that covers 10 packets.  How were those packets sent?  Were they
>     sent a back-to-back burst so "10 more" is in fact a back-to-back
>     burst that is 10 more than previously (or, 2x)?  Or, did we send
>     those 10 packets in 5 little bursts of 2 packets each so that
>     "10 more" is actually 18 more than the previous burst size---a
>     10x increase?  Of course, it could be BOTH for the same ACK!
>     I.e., the segments were sent 2 at a time and aggregated
>     somewhere in the middle.  This lack of clarity again makes the
>     choice of L feel pretty arbitrary.
>
> I agree we can elide L if pacing is in place.  But, twiddling with L
> by feel is crude and will produce an inconsistent approach to bursts
> that doesn't seem to me to be particularly helpful because we don't
> really grok the implications.
>
> allman
>