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

Ian Swett <> Thu, 16 July 2020 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA0753A0B32 for <>; Thu, 16 Jul 2020 12:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P_qHtH9G4Nuw for <>; Thu, 16 Jul 2020 12:22:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A422E3A0B2E for <>; Thu, 16 Jul 2020 12:22:37 -0700 (PDT)
Received: by with SMTP id x9so3371485ybd.4 for <>; Thu, 16 Jul 2020 12:22:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YCtU0yNW8buiuKB6C6v90BVdp9oIda1SQsGgAV1jbrI=; b=kQhLYbQ4MH9FwE9uF1lCmbyMbjn4zivZncbxh7wtuUZA3xcO57bk6/giDJOrTcEQq6 Tk1DQj0Q3L4HZ2l3zubRXGcwh3YcLbWtAtqtuNVuztPE8IcDxwwMuhEGzATqNbuiFiw/ bR+gs+Hp1mZHAgb/dW4n+2uq0CsGBBZrAhhQ8uLGCAVt1bXXApycNLigHKyJYkYZHh5f MwIuqCtohO5GQ7a9yUiura+slLk0Fxwj+fMGRdLWmG8eMbGYPA1UWPOF1zv+zE6b+ARL HfBTK8+Tpc4BROD/1l0+zVZX9JzjHH7lqRt5HShpXpnaxcrU8MfU6aN65W2C7coRgnh0 KQOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YCtU0yNW8buiuKB6C6v90BVdp9oIda1SQsGgAV1jbrI=; b=kRCX9bn1/9a9DvmcZ1K+DluzOnhtwBv0CG6Fg0TXL3aXKbgld1Nvw/GEx6vDuGgVwr BHLerD73DrU/WRCo7zhRxsQQ41Kqrfn5wcWgvNVfVfYm3E0fBQ6g+xQeqxBjFadL1qT2 LoQxvIyIeo1HU8ih6lY2RN/fFUpCw9ep0v6GDncbi8FCiiem7je5Abi+vRFkhwLjVwY4 l2Ye1rGZHAyMrLkjJ3OohZbVAu8792PIe2UukQzNd7HTgByO3ulKz1jA+sYLRsbtq6nv VFoUYP8By0JHMCm3LcmgvSwH6RXNCwFs7Rp0IKpUg8KsXSfnTi5Y0tOWTa8hrx0wRHge 9mJQ==
X-Gm-Message-State: AOAM533LPtCRDAdRSf29xMBT99if1WPb9iAF8246UqSqWiBrQb681C1k Hcu2glvVqskdyZpIBd3IMj1gYUqHrRiahHNnKq0q7V7U1GE=
X-Google-Smtp-Source: ABdhPJxq12F82BpEK1XGyWkCMSVMYexoTIBMcBSGozAgwUnlZi5gDVPk3TT3EeazkwYVScK0AHnJwjc9fMx8dcQQ6jY=
X-Received: by 2002:a25:b78a:: with SMTP id n10mr8490826ybh.494.1594927356672; Thu, 16 Jul 2020 12:22:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Thu, 16 Jul 2020 15:22:24 -0400
Message-ID: <>
Subject: Re: [EXTERNAL] Re: WGLC review of draft-ietf-quic-recovery-29
To: Praveen Balasubramanian <>
Cc: Gorry Fairhurst <>, IETF QUIC WG <>, Neal Cardwell <>, Yuchung Cheng <>
Content-Type: multipart/alternative; boundary="00000000000089f3ce05aa93f6dd"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jul 2020 19:22:40 -0000

Thanks for the comments, I filed #3918
<> and #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=> 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 <>
> *Sent:* Friday, July 10, 2020 1:21 AM
> *To:* Praveen Balasubramanian <>om>; IETF QUIC WG <
> *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 <> <>
> *Sent:* Thursday, July 9, 2020 1:39 AM
> *To:* Praveen Balasubramanian <> <>om>;
> IETF QUIC WG <> <>
> *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