Re: Unrecoverable loss pattern

Martin Thomson <> Sun, 25 February 2018 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2147E124D68 for <>; Sun, 25 Feb 2018 14:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, 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 TsgqiX5ntG3z for <>; Sun, 25 Feb 2018 14:47:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A38E2124BAC for <>; Sun, 25 Feb 2018 14:47:40 -0800 (PST)
Received: by with SMTP id y11so2483344otg.0 for <>; Sun, 25 Feb 2018 14:47:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XPWFmEucyLsqHnSqOolfjShFliguL2ehv7GUS9OKDlg=; b=soWuFBMhOqT+ftTzBVPYh0GPnDPkXIV3+ZZSkUvJm8iPwdlNblMsL+OIyOaQfKuKsh HMurpL2H3C8dX6vTdjaB7yVl2tP8B4lFOFixaMciKDDIQ7OlzqqHsWn6+GlQyseTIv0v konxUpyGu1NNjVS64MxlizhYIxzJotelFAOuaILHq5vk3ZK2iZkGwA9+0kzZpkGlVRur 4jvDOXbPba2NtOWz0KGC1yQTMKrwvGwWFnv8cxOUzZdRatUPsm3ZkFKWjh9yMch/LLaf QsJE1O3F60k1wOgaNYZOJ8ZDkJi4kCzQCVp57awuZpt5X3cTA2QOpR9SSLh2boWhche2 IXZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XPWFmEucyLsqHnSqOolfjShFliguL2ehv7GUS9OKDlg=; b=nZ+1lcF5abwrGS747HTFFg/dCrr0H5wAM+UrbBcsywPFLCquypZdorqAbAVcKB9Hva vVMCJFbxpmTPevkVoN9IPjHdWICKN/vCbtUQeweeo8BuYU96sHB6XMgKV8hAGw2B/8iT W94zpvYro8Mk8aOluNlZ8oJtkLkXOf5wVaKra456MzbWEpgpB+u30yjXcCoOroedKWmc xOfcRgNRvOdBxpn7lxeV0KxLfB6qZ/WGaIMD68SjR8DkfOETWUchujRuEXW4gREcx1dv paTwKVa23pKI7A8JR6V9pK9U1bG0CRBpK6G3eKfTz1nbG8XrqXLa1b+ohJWTPeadEPPE uGag==
X-Gm-Message-State: APf1xPCWgVO8OikfrEVRNNmMhUc/0MKBxCwR/emHJPAm5w/LcpQZGfC2 WMu/vJJp03FhgAgMQYktWIjUe7y0ZnOzALqxlLk=
X-Google-Smtp-Source: AG47ELsipv9HWy8HbX30FNXhqZWfoSHWpoluTItWXmbh0ib8FUDmthZuvAfBreAuvUdNlaIJcFe3pXZwupWYf8Fb61A=
X-Received: by with SMTP id o34mr6642966otd.352.1519598859949; Sun, 25 Feb 2018 14:47:39 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 25 Feb 2018 14:47:39 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Mon, 26 Feb 2018 09:47:39 +1100
Message-ID: <>
Subject: Re: Unrecoverable loss pattern
To: Marten Seemann <>
Cc: QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 22:47:42 -0000

I assume that this is the language you refer to:

   A server MUST process ACK frames in unprotected packets
   until the TLS handshake is reported as complete, or it receives an
   ACK frame in a protected packet that acknowledges all of its
   handshake messages.

That talks about ACK frames, not Finished.

On Mon, Feb 26, 2018 at 1:25 AM, Marten Seemann <>; wrote:
> 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?