Re: [tcpm] Linux doesn’t implement RFC3465

[Mark Allman <[e-mail]>]

>  “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