Re: [tcpm] AD Review of draft-ietf-tcpm-hystartplusplus-09

[Martin Duke <[e-mail]>]

To be clear, the non-normative experiment report can also say "we were also
running non-standard ABC with L=8", but as it stands the normative part
can't have a reference to L that requires 3465 to fully understand

On Thu, Sep 8, 2022, 10:00 Neal Cardwell <[e-mail]> wrote:

> On Thu, Sep 8, 2022 at 12:54 PM Martin Duke <[e-mail]>
> wrote:
>
>> Hi Neal, thanks for the data.
>>
>> Given its wide deployment, I'm happy for the spec to allow L_max =
>> infinity, assuming the community is fine with it.
>>
>> I don't care that much, in theory, whether L limits are defined in this
>> document or in another one. However, in practice adding about 2 paragraphs
>> to this document would allow us to obsolete 3465. If we can rapidly reach
>> consensus on this, it seems like the expeditious thing to do.
>>
>
> Thanks, Martin. Adding about 2 paragraphs to this document in order to
> allow us to obsolete 3465 sounds great to me. :-)
>
> The alternative is to simply eliminate L from Hystart++, and we "really
>> know" what people will do in production.
>>
>
> Eliminating L from Hystart++ sounds like a nice simplification. But there
> is also virtue in Microsoft documenting what is implemented and tested. So
> I don't have strong feelings about whether L is kept in Hystart++ or not,
> and I hope we hold up the Hystart++ draft due to issues surrounding L. :-)
>
> regards,
> neal
>
>
>
>>
>> On Thu, Sep 8, 2022 at 9:42 AM Neal Cardwell <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 7, 2022 at 5:46 PM <[e-mail]> wrote:
>>>
>>>> > On 7. Sep 2022, at 22:44, Martin Duke <[e-mail]>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Sep 7, 2022 at 1:15 PM <[e-mail]> wrote:
>>>> > > On 7. Sep 2022, at 21:40, Martin Duke <[e-mail]>
>>>> wrote:
>>>> > >
>>>> > > I would be happier with some sort of limit on L. Maybe: the
>>>> positive integer L SHOULD be 2 and MUST be no more than 8(?) But whatever
>>>> numbers the community is comfortable with are fine with me.
>>>> > Hi Martin,
>>>> >
>>>> > the crucial point here is that we know that MS used L = 8. But we
>>>> don't have any information,
>>>> > whether other values of L are worse or better, what the tradeoffs are
>>>> and in particular
>>>> > what traffic patterns impact the choice of L. Wouldn't we need such
>>>> an analysis / results
>>>> > from an experiment for selecting an upper limit L_MAX? I would assume
>>>> that it might
>>>> > have an impact whether pacing is used or not.
>>>> >
>>>> > Well the community has at least some data that L = 8 is safe on the
>>>> internet. Maybe some other practitioners have data for 16 or 32 or
>>>> whatever. It would be reasonable to set some sort of limit based on the
>>>> limits of our empirical limit.
>>>> Sure. My point was just that the results provided my MS show that L_MAX
>>>> <= 8 seems to
>>>> be safe in the scenario they looked at. But there is no statement that
>>>> L_MAX > 8 is
>>>> bad...
>>>> >
>>>> > It would be fine to say "one SHOULD NOT exceed L = foo if you're not
>>>> pacing"
>>>> >
>>>> >
>>>> > >
>>>> > > I'd also be happier with a cut-and-paste of those considerations
>>>> from 3465, which should not be a lot of work.
>>>> > >
>>>> > > The lower-effort approach is just to strike L from the document and
>>>> let people do what they've doing, which is use Ls well in excess of 2. But
>>>> I'd prefer we'd actually write it down because
>>>> > > (1) our standards are better if they reflect widespread behavior in
>>>> the internet; and
>>>> > I agree with the above.
>>>> > > (2) it means we can finally make 3465 historic, as we have
>>>> standards-track documents that cover virtually all of its material.
>>>> > >
>>>> > > If the community really cannot converge on sensible limits for L,
>>>> then I'd rather publish with no L than wait for a deadlock to resolve.
>>>> > In my view, the selection of L is not part of the core of the
>>>> document.
>>>> >
>>>> > This document standardizes a new slow start algorithm, which includes
>>>> L as a parameter, for which there is no standard.
>>>> My point was that there is no L_MAX given here.
>>>> >
>>>> > >
>>>> > > But as a way forward, I'd suggest:
>>>> > > 1) the authors propose text that sets bounds on L (a SHOULD and a
>>>> MUST) and cut-and-pastes the considerations.
>>>> > Aren't the consideration in RFC 3465 coming to the conclusion: L
>>>> SHOULD be 1, MAY be 2, MUST NOT be larger than 2?
>>>> > How to use the same considerations to come to a different conclusion:
>>>> L SHOULD be 2, MUST NOT be larger than L_MAX
>>>> > for L_MAX > 2?
>>>> >
>>>> > Re: SHOULD 1 or 2, I don't have a strong opinion but I feel like the
>>>> 3465 experiment shows that 2 is safe, and somewhat beneficial given the
>>>> prevalence of ack thinning? If there is no consensus for this, I'm happy to
>>>> go with 1.
>>>> >
>>>> > L_MAX: My preference is to set a value that is widely deployed with
>>>> good data that it is safe to do so
>>>> Let us see if people provide data which values are good and which
>>>> values are bad...
>>>>
>>>
>>> FWIW, Linux TCP has been using L_MAX=infinity since 2013:
>>>
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f9843a751d0a2
>>>
>>> IMHO trying to limit bursts with an L parameter is misguided:
>>>
>>> + AN L limit is only a partial solution; TCP RFCs still allow massive
>>> line-rate bursts of cwnd when restarting from idle, which is super-common
>>> in some very common Internet workloads: web traffic, streaming video, RPC.
>>>
>>> + To avoid such bursts, whether restarting from idle or not, TCP stacks
>>> should enable pacing.
>>>
>>> + Once pacing is enabled, having an L limit purely shoots your flow in
>>> the foot, causing it to fail to double cwnd each round trip in slow start
>>> in the very common case of the many ubiquitous aggregation mechanisms that
>>> cause ACKs to arrive for dozens of packets at a time (e.g.. Linux GRO/LRO
>>> commonly aggregate 45 packets into a single unit that is processed and
>>> ACKed as a unit).
>>>
>>> IMHO ideally burst control, pacing, and L limits should be separated
>>> from Hystart++, and should have their own RFC.
>>>
>>> And whatever is done, at a minimum Hystart++ should not depend on
>>> RFC3465 (ABC) (though it could mention it in passing to provide context).
>>>
>>> my two cents,
>>> neal
>>>
>>>