Return-Path: 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 7AD973A00E4 for ; Wed, 8 Jul 2020 14:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 foaiBuMLkrkh for ; Wed, 8 Jul 2020 14:30:11 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650121.outbound.protection.outlook.com [40.107.65.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FE63A00E3 for ; Wed, 8 Jul 2020 14:30:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TAIKD1pRqPzKHrJWnI4bW5tfMaKdKACwfcqhZhgUdjJ7WPHz0hZSoSAmK1GOOlMYhqtRPteOYv+GPvHpOdI18a7IEXeR7eICEk7OEAhvedvxCAZPmvgkNVmvrwP7AxlRmtKMCb5MDyTYRbcvh/tlJjV09UG6/SRwJpTnlIiSYoiWHK1S4cbXndRZGEATqWOksYrGUK5TyOZaSEoKYJULakoR3Mi25CylOo+hazlcBfU4lcN7/iW/KfBHKTQbipdclhBJs18U4MlF+cZhDZb/7L+UR//r/4NzOXjTFJrOTf1XpHVSwTkgsEiV9JaryKxXtDPmkwIaep2zYZe+EdXXMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fma25seJqYV+GsqSNDKIGAd6OYn0ci9w67tCxXb+8so=; b=h3x+6Q4cCSr35FU/FSOecU8bbVqjEj6Ca88AaE6Y6QORSQ0nv549Qm+ldp38pYw7fcGNCIgeM9Ecq6gfcWccfrkFGzth8Etnd7pXBToZ9M4wNehpM4AKabZjcwW4pWJWDOAOHL/GHnUGQmpqKSeyKfTN7zXLdgUNZ+KbU6iteSrW3GKqDzdRlKBPhoA5lu8gXn+2NvAZwNWPlUlxViCAqhPiMl8JnYRe98wwnuRxr4vwnOFdsUFVrzdV9J3yyrBKbsKpbdiqC1gKsPVLxlgOFeGx2cKqC2szMgOcEEjpB8SpKdpIO9hRNjF1naapxHDBoICP09HJdzUaUKwzK7ZQBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fma25seJqYV+GsqSNDKIGAd6OYn0ci9w67tCxXb+8so=; b=R308UJNyCZzoNtkzhf5RAYftiT98IerKg8czgOHgg3xNZV9k2z+ZiFz7zLEh12XMZhwlibJMCVQoXeUMYNOJHZc2qLm+AzJuGbHTzsGohRXF87zkFDIH+1tQz5YjQJlChnrs4QxIu3NvSZ8Sxf4BXa/Gx2wHftijOAWqhIYCplQ= Received: from MN2PR00MB0736.namprd00.prod.outlook.com (2603:10b6:208:1dc::17) by BL0PR00MB0817.namprd00.prod.outlook.com (2603:10b6:208:1c8::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3214.0; Wed, 8 Jul 2020 21:30:00 +0000 Received: from MN2PR00MB0736.namprd00.prod.outlook.com ([fe80::180c:4e10:79a8:e18e]) by MN2PR00MB0736.namprd00.prod.outlook.com ([fe80::180c:4e10:79a8:e18e%9]) with mapi id 15.20.3207.000; Wed, 8 Jul 2020 21:30:00 +0000 From: Praveen Balasubramanian To: IETF QUIC WG Subject: WGLC review of draft-ietf-quic-recovery-29 Thread-Topic: WGLC review of draft-ietf-quic-recovery-29 Thread-Index: AdZVbt/Rv8RxmVSLQP+4+5gZJ/6HOg== Date: Wed, 8 Jul 2020 21:29:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-08T21:29:58Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=38f37264-26b9-4a32-8fcb-b59ba0732dd4; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3:95d5:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 686a6004-d7ab-4cc2-d7dc-08d823861197 x-ms-traffictypediagnostic: BL0PR00MB0817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BQb2fUTUtCAWKYeg/ypCY/9GEkCzDPp3BH5ng2rwSCZ1JCU4OGqAkbBjeKQludp+1HxuQbklSgew1TwlnhcH7tOXB9nsoZMAwkb8aQzo96rsJyWJJVulhGOTVJbVJs63rNP/pU8pcNV/tYSvq4kbAxFFb1C02lmfOnV9G/ZZ7jbpiSCtPL0mj6VyUK9Eq54F92xaTpnn/sTxlIbdCeuhTPjBlKCsHe0ecdF2Px8ACKYPHtjZs4QQOLjX79MhXcbMpEaHXE5CrJQf5zKDhq3VYNvGCkUi1fDotKCQztJ9o3BRayUuE4FkhnrDH6rNkKVqDKePlufqtNZK6S6IRvj+gg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0736.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(376002)(346002)(136003)(39860400002)(33656002)(478600001)(7696005)(86362001)(52536014)(8676002)(8990500004)(83380400001)(5660300002)(9686003)(66476007)(76116006)(66446008)(64756008)(66556008)(66946007)(2906002)(186003)(8936002)(6916009)(6506007)(10290500003)(55016002)(82950400001)(82960400001)(71200400001)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 9a1mGpoWsy3Z10l/oZDfwc0wwLODG5r83hrwDgzQvduxg/0L+hdOX5r/wkS3Wt4oU+ZL0Pscw0Uny7SkqchQhLxYJrxg9jMrUXGKryRWRVtzTiMeaXkBAuGXZFT2P1GZDfrJwLt41TA2ny3HLo4vcQHWI0kfqGl4Bp+TGolBnka3V7PEifHIiEhn4FzZ0wZZsqGvMIqGhelSove5XMvbtyxRw2VaW8Q9vs93HHAvvtxytlCpUo7mxB0dS5KGH2GDUOZbUj8twaUDvbddYceSyJfo0Mvpt0pTSHEF+ncpgK/TSbg2gYzRWZZZ1p58NPh7hx1MO4961Qrnh5g6VMX4hxdy5lzWIpRBTYzV2wBP9E7d6bLrXJFzA2hWCXSUNYVCz2HWwOV/ACnmArllJJi2OwYZhzQk/PNyAn73Qp/32/y5nznxMU6FdYg4DFXnW4Q02fQiFFWNqs6DLxo85Hc+6VtFjzS4s2mafVkvL2KRU0vJC9ZpylhhrmF+kdtS8EZ+/UGfqodH090xaCNiaIzIBMb5PZ880HsTuHAIGoNsE0w= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB073663726DB5AFE6885D0A6BB6670MN2PR00MB0736namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0736.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 686a6004-d7ab-4cc2-d7dc-08d823861197 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2020 21:29:59.9165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4rH/upfLF5jZ8+66pRA2UTX8+1YZBAdJZZE4sIwyLQ0R3BB9TJby1lJnKtXfe+ReROhPx51iWY6g6lD8zp05knpVpOipdQu2aKcuDdCb4ms= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0817 Archived-At: X-BeenThere: quic@ietf.org 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: Wed, 08 Jul 2020 21:30:14 -0000 --_000_MN2PR00MB073663726DB5AFE6885D0A6BB6670MN2PR00MB0736namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a WGLC review of draft-ietf-quic-recovery-29. Mostly editorial but = some issues. Section 2 " are not acknowledged, declared lost, or abandoned along with old keys." -= -> are not acknowledged, declared lost, or discarded along with old keys." Discarding is the term used in the rest of the doc notably in section 2.4. = I see some reference to "abandon packets" in the transport draft as well. W= ould be good to use the same term for consistency everywhere. Section 4.4. "does not allow any acked packet to be reneged" --> "does not allow any ac= knowledged packet to be reneged" Section 4.7 "QUIC uses a probe timeout (see Section 6.2)," --> "QUIC uses a Probe Timeo= ut (PTO) (see Section 6.2)," Section 5.2 "If the path's actual RTT increases, the min_rtt will not adapt= to it, allowing future RTT samples that are smaller than the new RTT be i= ncluded in smoothed_rtt." Would it safer to reset min_rtt after persistent congestion is declared. Th= is is important so we can adapt to a consistent spike in RTT as a result of= a path change. Section 6.1.1 "Algorithms that increase the reordering threshold after spuriously detecti= ng losses, such as TCP-NCR [RFC4653], have proven to be useful in TCP and a= re expected to at least as useful in QUIC." It might be better to refer to RACK here which has an optional feature to i= ncrease reorder threshold in time. I don't know of any major implementation= s that do TCP-NCR but maybe I am mistaken. Section 6.2.1 "time threshold Section 6.1.2" --> time threshold (Section 6.1.2) "The life of a connection that is experiencing consecutive PTOs is limited = by the endpoint's idle timeout." Is there any specification of recommended values for idle timeout? Any valu= es lower than 9 seconds could adversely impact preserving of connectivity d= uring VM live migration. Section 6.2.4 "If the sender wants to elicit a faster acknowledgement on PTO, it can skip= a packet number to eliminate the ack delay." This adds some unnecessary complexity. Given that endpoint MAY send two ful= l-sized datagrams, isn't that a better technique than skipping packet numbe= rs? Section 7.8 "The congestion period is calculated as the time between the oldest and new= est lost packets: (3 - 0) =3D 3." --> "The congestion period is calculated = as the sent time difference between the oldest and newest lost packets: (3 = - 0) =3D 3." It might be worth noting that persistent congestion can be declared without= sending a PTO. Particularly because the example assumes PTOs. In the case = where app kept on periodically sending new data and no ACKs came back for t= he threshold and then an ACK came back and declared all packets sent before= it as lost. Section 7.9 "Implementations MUST either use pacing or another method to limit such bur= sts 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 l= oss. The MUST here seems unnecessary. It also conflicts with the RECOMMENDE= D in an earlier sentence. Section 8.2 "Endpoints can use PADDING frames or bundle acknowledgments with other fram= es to reduce leaked information." A reminder should be added here that PADDING counts towards in-flight so th= ere is a possible impact on performance. Section B.8 The function AreAllPacketsLost does not have any pseudocode. Thanks --_000_MN2PR00MB073663726DB5AFE6885D0A6BB6670MN2PR00MB0736namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a WGLC review of draft-ietf-quic-recovery= -29. Mostly editorial but some issues.

 

 

Section 2

" are not acknowledged, declared lost, or aband= oned along with old keys." -->  are not acknowledged, declared= lost, or discarded along with old keys."

Discarding is the term used in the rest of the doc n= otably in section 2.4. I see some reference to "abandon packets" = in the transport draft as well. Would be good to use the same term for cons= istency everywhere.

 

Section 4.4. 

 "does not allow any acked packet to be re= neged" --> "does not allow any acknowledged packet to be reneg= ed"

 

Section 4.7

"QUIC uses a probe timeout (see Section 6.2),&q= uot; --> "QUIC uses a Probe Timeout (PTO) (see Section 6.2),"

 

Section 5.2 "If the path's actual RTT increases= , the min_rtt will not adapt to it, allowing future RTT samples that are sm= aller than the  new RTT be included in smoothed_rtt."

Would it safer to reset min_rtt after persistent con= gestion is declared. This is important so we can adapt to a consistent spik= e in RTT as a result of a path change.

 

Section 6.1.1

 

"Algorithms that increase the reordering thresh= old after spuriously detecting losses, such as TCP-NCR [RFC4653], have prov= en to be useful in TCP and are expected to at least as useful in QUIC."= ;

It might be better to refer to RACK here which has a= n optional feature to increase reorder threshold in time. I don't know of a= ny major implementations that do TCP-NCR but maybe I am mistaken.

 

Section 6.2.1

"time threshold Section 6.1.2" --> time= threshold (Section 6.1.2)

 

“The life of a connection that is experiencing= consecutive PTOs is limited by the endpoint's idle timeout.”

Is there any specification of recommended values for= idle timeout? Any values lower than 9 seconds could adversely impact prese= rving of connectivity during VM live migration.

 

Section 6.2.4

"If the sender wants to elicit a faster acknowl= edgement on PTO, it can skip a packet number to eliminate the ack delay.&qu= ot;

This adds some unnecessary complexity. Given that en= dpoint MAY send two full-sized datagrams, isn't that a better technique tha= n skipping packet numbers?

 

Section 7.8

"The congestion period is calculated as the tim= e between the oldest and newest lost packets: (3 - 0) =3D 3." --> &= quot;The congestion period is calculated as the sent time difference betwee= n the oldest and newest lost packets: (3 - 0) =3D 3."

It might be worth noting that persistent congestion = can be declared without sending a PTO. Particularly because the example ass= umes PTOs. In the case where app kept on periodically sending new data and = no ACKs came back for the threshold and then an ACK came back and declared all packets sent before it as lost.=

 

Section 7.9

"Implementations MUST either use pacing or anot= her method to limit such bursts to the initial congestion window; see Secti= on 7.2."

This seems to preclude use of segmentation offload o= f sizes greater than IW. In datacenters we routinely send bursts that are h= igher without causing loss. The MUST here seems unnecessary. It also confli= cts with the RECOMMENDED in an earlier sentence.

 

Section 8.2

"Endpoints can use PADDING frames or bundle ack= nowledgments with other frames to reduce leaked information."

A reminder should be added here that PADDING counts = towards in-flight so there is a possible impact on performance.<= /p>

 

Section B.8

The function AreAllPacketsLost does not have any pse= udocode.

 

 

Thanks

--_000_MN2PR00MB073663726DB5AFE6885D0A6BB6670MN2PR00MB0736namp_--