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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Ian,

On Mon, Jul 20, 2020, 16:33 Ian Swett <[e-mail]> wrote:

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

Thanks for helping me understand - this is a stylistic change.

I've had a couple of conversations outside of QUIC recently with people who
were interpreting the two terms somewhat differently, so thought it a good
time to ask.

Best,

Spencer

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