Unrecoverable loss pattern

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

Return-Path: <martenseemann@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 24113126C25 for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 06:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aJowZdGFVdKf for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 06:26:04 -0800 (PST)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 5D4AD120227 for <quic@ietf.org>; Sun, 25 Feb 2018 06:26:04 -0800 (PST)
Received: by mail-ua0-x22a.google.com with SMTP id n48so8881104uae.13 for <quic@ietf.org>; Sun, 25 Feb 2018 06:26:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cF9cvKcwb3BYncLcqPm3fTQNh0/PR9fsPNmEHIi/mCc=; b=Z//jmTk22AdRh7Wse7SFBgvrj2ue7+I3JFppo/EBUfSDukzfE6YJnUY7Q4hW5aAT3w 2bi7tS3IH4z5bpLX12Wy49V3MLsI40as1/BffCW29/3hXNMFsaIo6wYrGzKXQRFPNCM0 UoyYvaZ6lVbXHVzNmzadNkDaHCKn2qLcSqyZyCYNlv9RH43E+ZiH1UxCVYzUNqIrj3jG v/1j/+J/ZloNdmug8X03xkI4g+N5ThHR0PUfRwX1vxvy74Iyjw4awUgK3YCR8U9TPK06 +iozba4lz2InzkojcRFZjpgzEs/SgImD+nq+o8MCVxWAuLY2j9CjfK5ll8id6fNRFakN M1iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cF9cvKcwb3BYncLcqPm3fTQNh0/PR9fsPNmEHIi/mCc=; b=ovQHH+mctu0jBTMfbjwATWY1JE0a9nV6bOE08SHb0F9/7y4AG0hpT9RYrIMiEAND7G 28bj4aJhr0wTJXFcDvbtDDD0keJGe/9M/5LA/+JswJ56fkt5khaxtKFUGtQycHkpkVsK lumwqzr6Z6xVeQWuSmpJh+S2RGUKbCL8SBgGN8VeVdIdziRoqHwwlHEw2LRpwsC23edn FBRet7GGYY9ijc2Pg2GRZlYQ7nUs2WVvzGe+TRYfoaT9kY18FaRFLEDNVgiFDBiNoP9G 16vu97rY9fYNWUECG2UWDhiwzQ1YhXXSfwkTEvuayAbxeLRyhkNBCsWZO6cY5eyPzkFA nnCg==
X-Gm-Message-State: APf1xPCh0enolV3PLrnpXSKjG1t/w6VgnIKz5495W9EJ5S6zF/5fneUZ RD6XrRuUlQh9d6Nt+MXZEFYq+VM3p9kYmYpOnHLV8A==
X-Google-Smtp-Source: AG47ELubiQ/8pB83azarjAnXi9+E6gjkMADzt15kqELKragKDvbSvdeoEmWuePJS6qV0A5cyWG1NmIgRYzyC23ChcJ0=
X-Received: by with SMTP id p46mr6010793uaf.134.1519568762799; Sun, 25 Feb 2018 06:26:02 -0800 (PST)
MIME-Version: 1.0
From: Marten Seemann <martenseemann@gmail.com>
Date: Sun, 25 Feb 2018 14:25:52 +0000
Message-ID: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.com>
Subject: Unrecoverable loss pattern
To: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="f403043c6cb8518c2b05660a2c42"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/G7FmZJvNnQOrA7JxjD3FE2SyeLM>
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 14:26:06 -0000

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