Re: WGLC review of draft-ietf-quic-recovery-29

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 09 July 2020 08:39 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFD93A0928 for <quic@ietfa.amsl.com>; Thu, 9 Jul 2020 01:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k9r50Iz_rnZ for <quic@ietfa.amsl.com>; Thu, 9 Jul 2020 01:39:32 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id DEACC3A0912 for <quic@ietf.org>; Thu, 9 Jul 2020 01:39:31 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5F4611B0007F; Thu, 9 Jul 2020 09:39:28 +0100 (BST)
Subject: Re: WGLC review of draft-ietf-quic-recovery-29
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>
References: <MN2PR00MB073663726DB5AFE6885D0A6BB6670@MN2PR00MB0736.namprd00.prod.outlook.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <53187d65-f7b9-b99a-f68b-b267303ab399@erg.abdn.ac.uk>
Date: Thu, 09 Jul 2020 09:39:27 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <MN2PR00MB073663726DB5AFE6885D0A6BB6670@MN2PR00MB0736.namprd00.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------8F2993EF6B57BD3E039F3D27"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SnZdrDu4gMyxCnBVUDTMnnc1lVg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 08:39:34 -0000

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