RE: Unrecoverable loss pattern

Nick Banks <nibanks@microsoft.com> Sun, 25 February 2018 16:52 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 F0A24126CF9 for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 08:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_H2=-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 h7vQ1qgvieXg for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 08:52:04 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5BE1201FA for <quic@ietf.org>; Sun, 25 Feb 2018 08:52:03 -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=lMDh2McJtPl9Gk060gyyuKe9BZ1MQswrbxPh8BowHc4=; b=Eh+JPgt4/Qp4SUYAuIPoEPQVrzRDXN7UVrOrSCPynkX/XHzWzKA9ROKdxrQBSfGv9ODgi6Jgp4B77YBfQ41CoE17TNdAJjJnWwRE7r/dBLlJ9W2g6sm1TKAKKHBdZVyVpuJWeG+Ym3eNS3GFovZtaFcvxEeR08/kOO2k9zZ12KQ=
Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0787.namprd21.prod.outlook.com (10.175.132.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Sun, 25 Feb 2018 16:52:02 +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.0567.002; Sun, 25 Feb 2018 16:52:02 +0000
From: Nick Banks <nibanks@microsoft.com>
To: Marten Seemann <martenseemann@gmail.com>, QUIC WG <quic@ietf.org>
Subject: RE: Unrecoverable loss pattern
Thread-Topic: Unrecoverable loss pattern
Thread-Index: AQHTrkSWFslkSBt3zkyfQlKulmkzQqO1VDuw
Date: Sun, 25 Feb 2018 16:52:02 +0000
Message-ID: <BN6PR21MB0178F0351B568A8EBCED2979B3C20@BN6PR21MB0178.namprd21.prod.outlook.com>
References: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.com>
In-Reply-To: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.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-02-25T16:51:59.9820395Z; 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:b::7ae]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR21MB0787; 7:0pOK0qkJ5LWZra9EsmalKNq0BEoLkuNZEG8Y22Dro4XSJX/21VbfEYbSeBH/mJLd8gglDHmJzG6vTLTkJ+HlCve/yt5TwQvdDRx9/voIwwtVQCMqBrjLA+c9CcukOEdwlctm0YYSJaaT7nNiRmNBNEy/hxWqgmg/JK7lxEhGnA4Oh0jBcqMDRhULivS6Hn/zf+Xp+gW35Qwx/eUzavf0wGDAI+7SeVqr5kcPLQhV1oEjT/cAnylTN7Am8b/FmO/Y
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 6ef0e3ca-fda5-4b5d-47ab-08d57c7017db
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:BN6PR21MB0787;
x-ms-traffictypediagnostic: BN6PR21MB0787:
x-microsoft-antispam-prvs: <BN6PR21MB0787EBFB65C6AA207AB9FBB9B3C20@BN6PR21MB0787.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(3231220)(944501187)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR21MB0787; BCL:0; PCL:0; RULEID:; SRVR:BN6PR21MB0787;
x-forefront-prvs: 05947791E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(39380400002)(396003)(39860400002)(199004)(189003)(7116003)(14454004)(5660300001)(186003)(39060400002)(8676002)(2950100002)(86362001)(86612001)(102836004)(6436002)(55016002)(106356001)(110136005)(6246003)(53936002)(6306002)(54896002)(10290500003)(77096007)(478600001)(59450400001)(7736002)(9686003)(74316002)(53546011)(6506007)(8990500004)(105586002)(6116002)(790700001)(6346003)(10090500001)(68736007)(2906002)(99286004)(97736004)(316002)(7696005)(229853002)(76176011)(81166006)(3660700001)(22452003)(81156014)(2900100001)(3280700002)(3480700004)(33656002)(25786009)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0787; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com;
x-microsoft-antispam-message-info: YQO9lR566T37a+6vgPqFDKKSfw1dlIfHj7z5wYbO8eeObqOFZvsVdTc5xx7uLP4iwqSKBtduuN25wl5A1Kk19a17UnH/lshAbJnxD+Qm+25Q+ePvPEzfunvBRcdNtOUY+4M+Wta6+SQAVxAR2GubUkCM7PzW7ZhkLI7411FywXM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0178F0351B568A8EBCED2979B3C20BN6PR21MB0178namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ef0e3ca-fda5-4b5d-47ab-08d57c7017db
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2018 16:52:02.0752 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0787
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pzRNdOQo1eM8UrilvaSmuKNWQzU>
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: Sun, 25 Feb 2018 16:52:06 -0000

Perhaps 6.1.2 should be changed just to say the server must continue to process unprotected packets until all the handshake packets are received, and remove the part about receiving an ACK that acknowledges its handshake messages?

- Nick

From: QUIC <quic-bounces@ietf.org> On Behalf Of Marten Seemann
Sent: Sunday, February 25, 2018 6:26 AM
To: QUIC WG <quic@ietf.org>
Subject: Unrecoverable loss pattern

I’ve been playing around with QUIC loss recovery and in my tests I’m encountering one specific loss pattern which it seems impossible to recover from. It's pretty rare, because there are a couple of conditions that must be fulfilled for it to occur:

1. Client and server perform the handshake, no packets are lost so far. Client and server both arrive at the CONNECTED state, and the server receives all ACKs for handshake packets it sent. The client receives ACKs for all handshake packets except for the one containing the FINISHED message is lost (the packet containing the ACK for the FINISHED is lost).
2. The client starts using 1-RTT keys, and it sends two packets: First, a packet only containing an ACK, and then a packet containing stream data (e.g. a request). The request packet is then lost.
3. The server receives the ACK in the 1-RTT packet, and it stops accepting unencrypted packets according to 6.1.2 of the TLS draft. It doesn’t generate an ACK in response, since the packet only contained an ACK.
4. The client is now missing acknowledgements for two packets: the (unencrypted) packet containing the FINISHED message, and the (1-RTT) packet containing the request. It runs its loss recovery algorithm (OnLossDetectionAlarm), and since there is one outstanding handshake packet, it retransmit all outstanding handshake packets.

Now we’ve run into a situation we can’t recover from: The server won’t even open packet sent as a retransmission (since these packets are unencrypted, and arrive after it already received a 1-RTT packet), and the client will never retransmit the request packet. Furthermore, the server won't send any other packets, since it's just waiting for a request from the client.

I think the solution for this is to also retransmit 1-RTT packets in a case like this. Can we just apply the normal retransmission rules in OnLossDetectionAlarm, even if there are still handshake packets outstanding?