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

[Ian Swett <[e-mail]>]

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