Re: Unrecoverable loss pattern

Martin Thomson <martin.thomson@gmail.com> Sun, 25 February 2018 22:47 UTC

Return-Path: <martin.thomson@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 2147E124D68 for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 14:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: 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 TsgqiX5ntG3z for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 14:47:40 -0800 (PST)
Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 A38E2124BAC for <quic@ietf.org>; Sun, 25 Feb 2018 14:47:40 -0800 (PST)
Received: by mail-ot0-x230.google.com with SMTP id y11so2483344otg.0 for <quic@ietf.org>; Sun, 25 Feb 2018 14:47:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.157.12.229 with SMTP id o34mr6642966otd.352.1519598859949; Sun, 25 Feb 2018 14:47:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Sun, 25 Feb 2018 14:47:39 -0800 (PST)
In-Reply-To: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.com>
References: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 26 Feb 2018 09:47:39 +1100
Message-ID: <CABkgnnWuXJb2_BcfU4N=ODwy5JDZKBBd6TyhFmXLbPgVrvCoEA@mail.gmail.com>
Subject: Re: Unrecoverable loss pattern
To: Marten Seemann <martenseemann@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/o5Q73QErIGBc7r6-oJ04gUpme2s>
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 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 <martenseemann@gmail.com>; 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?
>
>