Re: Unrecoverable loss pattern

Marten Seemann <> Sun, 25 February 2018 17:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C773126CF9 for <>; Sun, 25 Feb 2018 09:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KnXMPtDjZBYY for <>; Sun, 25 Feb 2018 09:02:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49E6E120726 for <>; Sun, 25 Feb 2018 09:02:15 -0800 (PST)
Received: by with SMTP id m43so9040541uah.1 for <>; Sun, 25 Feb 2018 09:02:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id x12mr2992854uaj.114.1519578133835; Sun, 25 Feb 2018 09:02:13 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Marten Seemann <>
Date: Sun, 25 Feb 2018 17:02:03 +0000
Message-ID: <>
Subject: Re: Unrecoverable loss pattern
To: Nick Banks <>
Cc: QUIC WG <>
Content-Type: multipart/alternative; boundary="089e082508e0e0371005660c5ac1"
Archived-At: <>
X-Mailman-Version: 2.1.22
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: 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 <> 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 <> *On Behalf Of * Marten Seemann
> *Sent:* Sunday, February 25, 2018 6:26 AM
> *To:* QUIC WG <>
> *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?