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

[Praveen Balasubramanian <[e-mail]>]

Within data center mainly. To hit 40 Gbps line rate you effectively have to batch as much as you can to minimize the CPU processing costs. The burst size today is capped to 64k in most cases for TCP. Now that we have segmentation offload for UDP the same should apply. Even for Internet facing traffic, the bursts primarily impact the first hop within the datacenter because subsequently you get statistical multiplexing from ToR switch handling traffic forwarding for many flows and ports.

Ok understood about there being no conflict. But I still contend that the MUST regarding burst size is way too restrictive. We should allow for experimentation here. Or present data that this is universally bad on all networks. Current production use of TCP shows there is no major problems with bursting higher. In fact for low latency same rack scenarios this will boost receive performance as well due to better opportunity for LRO etc.

From: Gorry Fairhurst <[e-mail]>
Sent: Thursday, July 9, 2020 1:39 AM
To: Praveen Balasubramanian <[e-mail]>; IETF QUIC WG <[e-mail]>
Subject: [EXTERNAL] Re: WGLC review of draft-ietf-quic-recovery-29


Hi Praveen,
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.
Is that within data centres? or from data centres to Internet destinations? ... if the latter, how can the sender be sure this is not impacting other traffic?

The MUST here seems unnecessary. It also conflicts with the RECOMMENDED in an earlier sentence.

I actually don't see this as conflicting. The recommendation in this section is to pace. The requirement is that sender limits burst, using some method, to the size of IW.

Gorry