IETF Logo Mail Archive

Definition of Recovery Period End

Nick Banks <nibanks@microsoft.com> Wed, 17 January 2018 00:35 UTC

Return-Path: <nibanks@microsoft.com>
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 776EC12EB60 for <quic@ietfa.amsl.com>; Tue, 16 Jan 2018 16:35:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pDxPGiYEUlq0 for <quic@ietfa.amsl.com>; Tue, 16 Jan 2018 16:35:55 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0106.outbound.protection.outlook.com [104.47.41.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB161270A3 for <quic@ietf.org>; Tue, 16 Jan 2018 16:35:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jLv8HdmqawXxBr2UviLR9rTSqSuJ/gBt3D5NXJA5tX0=; b=Uv5kup5qaevoFLbGYjqvk+kCNiRwqvIN0ht/C89ZPT6YYw///oNFf4/bJOKP6RKXtk/uU0ct5almBUle3DnAxC17BenwQCY37pyROLJXsBelIlsDjn1DPIsUeZn5E/VFIjYeg62iEKMluXsznBkU+HTsqjzs80Mh+NbZKtJPD5A=
Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0146.namprd21.prod.outlook.com (10.173.199.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.428.4; Wed, 17 Jan 2018 00:35:53 +0000
Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0428.002; Wed, 17 Jan 2018 00:35:53 +0000
From: Nick Banks <nibanks@microsoft.com>
To: IETF QUIC WG <quic@ietf.org>
Subject: Definition of Recovery Period End
Thread-Topic: Definition of Recovery Period End
Thread-Index: AdOPKyC5dkpgelaZSFyTiB2jNW8J3g==
Date: Wed, 17 Jan 2018 00:35:53 +0000
Message-ID: <BN6PR21MB0178ECF15AA5E99508B897F3B3E90@BN6PR21MB0178.namprd21.prod.outlook.com>
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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-01-17T00:35:52.0403266Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:2::2ba]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR21MB0146; 7:KjtWvlaQ8MNCfTS7PSYcBwo8Y9TTBHY6Rq2mYDFb1ua6GsCfDnBUeQXjima11pwe9WM2g02SJBRVdR0miG8HMRTYbmF1qSa8HFbCYW3wG74gfdLqrn+cdGQIvYTwWsMmS1rhfayej+n9rod8G9GPHoqYn07WIn5qvURrmIVVltSz5+kWQygU98aeC4KOWP27cePhNUAx5o4SQYwBtybL5nqgO2kulTMlfKQujLNi895ABvgM67LBu109RecH1kqP
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 125630a8-e55b-437e-d463-08d55d42443c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7193020); SRVR:BN6PR21MB0146;
x-ms-traffictypediagnostic: BN6PR21MB0146:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com;
x-microsoft-antispam-prvs: <BN6PR21MB0146FBE90062484FB3C28FA7B3E90@BN6PR21MB0146.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231040)(2400039)(944501161)(6055026)(61426038)(61427038)(6041268)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR21MB0146; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:BN6PR21MB0146;
x-forefront-prvs: 0555EC8317
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39380400002)(366004)(396003)(39860400002)(189003)(199004)(55016002)(10090500001)(6306002)(9686003)(54896002)(6506007)(68736007)(53936002)(74316002)(6436002)(22452003)(7736002)(33656002)(2906002)(7696005)(5660300001)(316002)(3280700002)(3660700001)(97736004)(8676002)(14454004)(6116002)(790700001)(6916009)(81156014)(10290500003)(8936002)(81166006)(8990500004)(106356001)(105586002)(2900100001)(25786009)(86612001)(102836004)(77096006)(99286004)(86362001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0146; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: iwUHX1OjXlBHhWT190vQBm2ed6NfOIxF/6quKGRjHuop6J92nOa6A+QFzBwFuBYJ9ogIg+lu+1/1rSN05doYaw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0178ECF15AA5E99508B897F3B3E90BN6PR21MB0178namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 125630a8-e55b-437e-d463-08d55d42443c
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 00:35:53.5292 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0146
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/fGUjdaEJdN9U_uGRZK6-OLK_EiE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 17 Jan 2018 00:35:57 -0000

Asking this on here per recommendation on GitHub:

According to the spec, recovery starts with detection of a lost packet and ends with the acknowledgement of a single, newly sent packet. Why isn't recovery ending only after all the information in the frames that were lost prior to the recovery period have been acknowledged? This way would seem more inline to what TCP does today.

For instance, if 4 packets worth of STREAM frames and a MAX_DATA frame were lost, why shouldn't recovery last until all that data had been resent and acknowledged?

Thanks,
- Nick Banks

v2.23.0 | Report a Bug | By Email