Re: [EXTERNAL] Re: WGLC review of draft-ietf-quic-recovery-29

[Ian Swett <[e-mail]>]

Most of the items which I felt were somewhat deployment-specific
constants(ie: Initial Window and Initial RTT) are 'RECOMMENDED' in the
current recovery draft, so I thought it'd be preferable to keep that
convention.

On Mon, Jul 20, 2020 at 5:30 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hi, Ian,
>
> On Mon, Jul 20, 2020 at 11:49 AM Ian Swett <ianswett=
> [e-mail]> wrote:
>
>> I think it's ok to include burst limits in the set of things we expect
>> may be different in DCs, but if we do that, I'd prefer to use the
>> RECOMMENDED rather than SHOULD,
>>
>
> Aren't RECOMMENDED and SHOULD equivalent in
> https://tools.ietf.org/html/rfc2119?
>
> Or am I misunderstanding your point?
>
> 3 <https://tools.ietf.org/html/rfc2119#section-3>. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
>
>
> Best,
>
> Spencer
>
> since there are a number of SHOULDs which I believe apply both to the
>> public internet and to DCs.  Then we could add a note at the top about how
>> there are some values which are RECOMMENDED, including X, Y and Z, and
>> those recommendations are expected to be good choices for most, but not all
>> environments.
>>
>> In terms of text, I'd suggest taking Neal's suggestion and dropping an
>> explicit mention of the public internet:
>>
>> Implementations MUST either use pacing or another method to limit such bursts.
>>
>> It is RECOMMENDED that implementations limit bursts to the initial congestion window; see Section 7.2 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-quic-recovery-29%23section-7.2&data=02%7C01%7Cpravb%40microsoft.com%7C9df3e5f4f0ca4e586f0908d824e0a3ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637299894526657906&sdata=ze%2F7SpKUbrdgwI6m%2BS6uEGSBgc2NapVtPn9vkOYFjVs%3D&reserved=0>.
>>
>>
>> On Sun, Jul 19, 2020 at 4:08 PM Praveen Balasubramanian <pravb=
>> [e-mail]> wrote:
>>
>>> >> There's a way of satisfying both desires: have the NIC handle the
>>> pacing.
>>>
>>> Yes letting the NIC handle pacing will make improve CPU efficiency and
>>> improve accuracy due to fine grained hardware timers. But that’s in the
>>> future. Today’s NICs don’t pace large send offloads for TCP or UDP.
>>>
>>>
>>>
>>> >> Perhaps we can have a principle here: recommendations that are
>>> specific for Internet use are just that, and we use SHOULDs for those. IW10
>>> makes sense based on this, and I would then also be fine with changing the
>>> MUST to a SHOULD. Perhaps we can state this principle upfront.
>>>
>>> I like the idea of stating that principle up front. SHOULD would be
>>> sufficient resolution for the burst size issue.
>>>
>>>
>>>
>>> *From:* QUIC <[e-mail]> *On Behalf Of * Jana Iyengar
>>> *Sent:* Friday, July 17, 2020 7:18 PM
>>> *To:* QUIC WG <[e-mail]>
>>> *Subject:* [EXTERNAL] Re: WGLC review of draft-ietf-quic-recovery-29
>>>
>>>
>>>
>>> There's a protocol question and there's a question of endpoint behavior.
>>> In terms of the protocol itself, yes, there's no real need to distinguish
>>> between Internet and DC environments; we've tried to ensure that the
>>> protocol can be used broadly. My point was that the constants in the spec
>>> were based on what we believe to be true for the public Internet, and not
>>> for DC environments.
>>>
>>>
>>>
>>> That said, perhaps I was a bit too hasty. IW10 and InitialRTT values are
>>> the others I was thinking about, but those are recommendations in the spec,
>>> not requirements. And as Ian notes, there's no minimum timeout anymore.
>>>
>>>
>>>
>>> Perhaps we can have a principle here: recommendations that are specific
>>> for Internet use are just that, and we use SHOULDs for those. IW10 makes
>>> sense based on this, and I would then also be fine with changing the MUST
>>> to a SHOULD. Perhaps we can state this principle upfront.
>>>
>>>
>>>
>>> Ian, I share your hesitation that we don't want to make a distinction
>>> between private and public networks, but we already allow for
>>> implementations to do that with a different IW and Initial RTT. Is it
>>> different when talking about burst limits?
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jul 17, 2020 at 3:07 PM Jeremy Harris <[e-mail]> wrote:
>>>
>>> On 08/07/2020 22:29, Praveen Balasubramanian wrote:
>>> > Section 7.9
>>> > "Implementations MUST either use pacing or another method to limit
>>> such bursts to the initial congestion window; see Section 7.2."
>>> > This seems to preclude use of segmentation offload of sizes greater
>>> than IW.. In datacenters we routinely send bursts that are higher without
>>> causing loss. The MUST here seems unnecessary. It also conflicts with the
>>> RECOMMENDED in an earlier sentence.
>>>
>>> There's a way of satisfying both desires: have the NIC handle the
>>> pacing.
>>> --
>>> Cheers,
>>>   Jeremy
>>>
>>>