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

[Ian Swett <[e-mail]>]

Thanks for the comments, I filed #3918
<https://github.com/quicwg/base-drafts/issues/3918> and #3919
<https://github.com/quicwg/base-drafts/issues/3919>

For my background, are you aware other transport RFCs have normative
statements that only apply to the public internet?  Also, if you're that
well buffered and the bursts are that large, do you still start with IW10,
or do you start with a larger window?

Thanks, Ian

On Fri, Jul 10, 2020 at 1:11 PM Praveen Balasubramanian <pravb=
[e-mail]> wrote:

> Precluding bursts higher than 10 packets is simply not viable or practical
> at really high data dates and is a major regression from the way TCP works
> today. QUIC is a general purpose transport and not scoped to the Internet
> only. On a side thread around Linux TCP behavior Neal suggested some
> alternate text to scope this to Internet facing traffic but my contention
> still holds that there are many networks where higher bursts are not a
> problem and we should not restrict those use cases.
>
>
>
> *From:* Gorry Fairhurst <[e-mail]>
> *Sent:* Friday, July 10, 2020 1:21 AM
> *To:* Praveen Balasubramanian <[e-mail]>; IETF QUIC WG <
> [e-mail]>
> *Subject:* Re: [EXTERNAL] Re: WGLC review of draft-ietf-quic-recovery-29
>
>
>
> Thanks Praveen,
>
> I'd like to talk more, see below:
>
> On 09/07/2020 17:11, Praveen Balasubramanian wrote:
>
> 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.
>
>
>
> I get this for this use-case and comments on high-speed NICs. I agree
> offload is important.
>
> 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.
>
> I am not sure. The IW spec for TCP was based on evidence back around 2010,
> and the IETF agreed in RFC6928 that a burst size of 10 was acceptable as an
> EXP spec for TCP.
>
> I think we can safely refer to that - even perhaps take the leap-of-faith
> that EXP for TCP is equivalent to PS for QUIC, given subsequent
> experience.  I think the IW  **is** the burst size that the IETF should
> specify (because it's dictated by buffering that is expected on the path).
>
> I see opportunities here for experimentation and measurement
> opportunities, and new specs can be proposed. Or the Specs can be recast
> with more detail. I also know that practical experience is that many people
> have configured (probably tested, I hope) much larger IW's - and I'd hope
> they also make a reasonable effort to monitor for possible interactions
> with other Internet applications and services (as per section 12 of
> RFC6928).
>
> Or present data that this is universally bad on all networks.
>
> I think you touch on something that the IETF hasn't been great at talking
> about:
>
> I could myself indeed likely produce data this shows this is "bad" in some
> networks that I value, and also show side-effects of collateral damage to
> other flows and adverse effects of line-rate bursts into equipment with
> small buffers. I don't know how useful that would be at all.
>
> The IETF has typically defined a spec for endpoint. The way a modern
> endpoint is implemented can be quite different in a DC from a single device
> connected to the Internet. In a DC, I understand it is common  to
> distribute transport functions to other parts of the network. e.g.: DDOS
> protection could be done on a server; or by a box in front of it -
> similarly what matters to the network CC is the  bursts of traffic that
> leaves a DC within a flow to a local receiver, not what leaves a particular
> server within the DC network - I think in future we may do well to consider
> these differences?
>
> 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.
>
> It's also possible that QUIC LRO (or whatever) includes some notion of
> per-flow burst-mitigation. Is that impossible?
>
> However, I personally would not hold-up QUIC, to arrive at a new consensus.
>
> Gorry
>
>
>
> *From:* Gorry Fairhurst <[e-mail]> <[e-mail]>
> *Sent:* Thursday, July 9, 2020 1:39 AM
> *To:* Praveen Balasubramanian <[e-mail]> <[e-mail]>;
> IETF QUIC WG <[e-mail]> <[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
>
>
>
>