Re: Unrecoverable loss pattern

Marten Seemann <martenseemann@gmail.com> Sun, 25 February 2018 17:02 UTC

Return-Path: <martenseemann@gmail.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 6C773126CF9 for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 09:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KnXMPtDjZBYY for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 09:02:15 -0800 (PST)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E6E120726 for <quic@ietf.org>; Sun, 25 Feb 2018 09:02:15 -0800 (PST)
Received: by mail-ua0-x235.google.com with SMTP id m43so9040541uah.1 for <quic@ietf.org>; Sun, 25 Feb 2018 09:02:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZbTv0YU/8FTQEjx5BjPPOHq03JeACv/EkE9y81uL5uI=; b=VOQxaQ34/URTpq4sq0xFH+leF0ESiiQ6ratsFPc45wMG/VlsWkK6nnedFtEB/iVZ0W RxufRclCmKYtCAQEbdM9xoCqeBP+SPYRK+JvbD0/zu/dY25RJ+dq6N9iry/p4KB40r/A oH2Mcyn6Feo7ssPeMPay+Hb3Qxm+w7TLWRcAAPp9g4SZ8PzahJf1TVzYXSzp32Tnni1i ea/Zfmr6mNNB2RIRs2Shbg2VdCo1ZjM4C7mZInksdJBsF2B8K9GFz1Z/9Qw+RrYHJra2 tlZspySkeSDXZBvVgXLyw3ufsSlAIYekceCE1AGu5lSjryyp5Zu/YQvzE72mWIi0Q+xt fPdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZbTv0YU/8FTQEjx5BjPPOHq03JeACv/EkE9y81uL5uI=; b=tkHHtRPqkIVN4K+Y2SGtB3KkP4+rJed5xZMMnyMn1BBwSKUUKHAfotl+WltNqqMt/1 XEpb1RI/L2zJf3bYvnCnITxJPz5dFxxzkDht8My9qqqev5aoLf1YxcqQoshNqsy7pVzz oBVj3D6QMwVEp0TA+kondfj8xxESRXog1BMKlbgLtn0OqT59CB7NGZC8jTV8tvFyYZVf 9p93f50FfV1IxhiuC/Sf9NooJ+BETZvGmu0fIkGliqZArHavs4eoYKRudRcbV+0Y0UIg soBV/3mvtHEW7PAYRirlur0dqXgJp7E003vLfcsf6wrLqR4CbVzxbYi8vC/kKza2z4V1 HzXA==
X-Gm-Message-State: APf1xPCSo4qy7kb0D2/Hr2J5oqNu39poZveJOXfZORVr+Uk7y8X5RaZz mcuZvqk5BIYEhU+RK/cLdxneEoVCf8QVnlsC+Sc=
X-Google-Smtp-Source: AG47ELvYla+Bpbal9seK/d0Uw178TEqsVZafnTU3qkYf+C69jlej/mwNuAbYkNwOctYikQJ/onpZ5AuA4Wp7yDkNIhA=
X-Received: by 10.159.47.12 with SMTP id x12mr2992854uaj.114.1519578133835; Sun, 25 Feb 2018 09:02:13 -0800 (PST)
MIME-Version: 1.0
References: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.com> <BN6PR21MB0178F0351B568A8EBCED2979B3C20@BN6PR21MB0178.namprd21.prod.outlook.com>
In-Reply-To: <BN6PR21MB0178F0351B568A8EBCED2979B3C20@BN6PR21MB0178.namprd21.prod.outlook.com>
From: Marten Seemann <martenseemann@gmail.com>
Date: Sun, 25 Feb 2018 17:02:03 +0000
Message-ID: <CAOYVs2pmmCqUFCf91VhUza962qwK734DyD86+k1TsXrb0WfCnA@mail.gmail.com>
Subject: Re: Unrecoverable loss pattern
To: Nick Banks <nibanks@microsoft.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="089e082508e0e0371005660c5ac1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ToJjnanOcgDqY5vk8QHWtfLHFFw>
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 17:02:17 -0000

I don’t think this will fix the problem. All handshake packets (sent by the
server) were received by the client and acknowledged (in the first 1-RTT
packet sent by the client).

On Mon 26. Feb 2018 at 00:52, Nick Banks <nibanks@microsoft.com>; wrote:

> 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?
>
>
>