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

[Praveen Balasubramanian <[e-mail]>]

>> 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]<mailto:[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