Hole in loss recovery algorithm?

Martin Duke <martin.h.duke@gmail.com> Wed, 29 April 2020 21:23 UTC

Return-Path: <martin.h.duke@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 36D9E3A186B for <quic@ietfa.amsl.com>; Wed, 29 Apr 2020 14:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 Y5F39Q1hZ0uQ for <quic@ietfa.amsl.com>; Wed, 29 Apr 2020 14:23:27 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 7E2FF3A186A for <quic@ietf.org>; Wed, 29 Apr 2020 14:23:27 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id e9so3858154iok.9 for <quic@ietf.org>; Wed, 29 Apr 2020 14:23:27 -0700 (PDT)
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=jEt7X7GU7NUbWpIvWye+DYQsDyuzIM3YMJZXkhjNK80=; b=Rh80jiihDQZ2zdAkNBy7Etl7k+ldnpbCPfPax2PudXKIPO7j6VMtGVsKpKylzTfQum bYiNX30riDCmfsmf30284NKTat3zXjowiB+pxc6skzTBvYGZzOv7CJxTMEHzMlKBMdNL 1zwPwJPU7Ugnl+1zJkEM8CR/8B1ny3dGPED2X1pSSf+hb+utZDFMZm8dQZwNxnxBWyxR KdOvWJsKwfENkO/x4lXtMKlLBhtYKRFu8FLaj3xQaJPzdo/u0d3WjEHHdYogHdcgFdM0 VWOMnCWvbHLlIU4qBGBdXeqyuPOGx28kBehYGF6yuUWQ4qMyPgMVSTClmfWTFQfJOvii fUVA==
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=jEt7X7GU7NUbWpIvWye+DYQsDyuzIM3YMJZXkhjNK80=; b=GvyxT8DzQefpPjI7vJUtaFp96gRoI0KpF1z8rYbwIOShrcqEmSmEKmGqmJXQwwwFUx zb1fL+h7cbYACujl0beFv86FFZSyKwoXSrML3XQc7xIe/Xzr+fzJQzyGyF/0K/XsIhhM eR0wgrwyHtQLfttfpUg/+aeV1mBIvRxkyKNqklz7hSnuGv84duCGXyQ/kwc+jUASG8HT HwZRvilaJWkoY2j/5eZCiss5ArX/0epE96G+lG+IE5ZFLTcNvk8LPJF1UZa6Lj4E8Q0S B2t0lzd6LweX8JBZE2gqTOlzpiRxtavqryWvrgaSF104c2yCAK68+iskzbUF7TNUv60W C16w==
X-Gm-Message-State: AGi0PuYMIZHlkOsUv1S+CiHXJk1XQe3KwQhmLET6fmxd6Ykcj334WLgo 610c+WbuOlDxo8GAvQOBhnDBUssQt9LFtGko7y7NbV/m
X-Google-Smtp-Source: APiQypKDa9+1fhP/AHDfFChygo9YfvWWlQZjMjwBT2lSpDOKL73eVM3xsbog+LzCf0binO10RCvMwpFffehce30a5e0=
X-Received: by 2002:a02:5249:: with SMTP id d70mr32570jab.121.1588195406455; Wed, 29 Apr 2020 14:23:26 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 29 Apr 2020 14:23:15 -0700
Message-ID: <CAM4esxQYh3W2GW-kxsBDw_Z8YLB3+-CSyLZsFQXp+LTxk92yNw@mail.gmail.com>
Subject: Hole in loss recovery algorithm?
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000009258d05a4748f9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/y6aoSXpiShx2BEE_9qjmwKJr8Ss>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 29 Apr 2020 21:23:30 -0000

I'm probably missing something silly, but I'll file an issue if there is in
fact a problem here:

- Server sends its handshake flight and some 1RTT data.
- The PTO is timer is set for the handshake data only per 5.2.1 of
quic-recovery.
- HS ACKs arrive, but the 1RTT is lost.
- Client Finished arrives.

If this order of operations occurs, and there is no further 1RTT
communication, is the 1RTT ever going to recover? A literal reading of the
spec, if IIUC, is that when the HS acks arrive we're going to cancel the
PTO timer and, as the handshake is not yet complete, we will not restart it
for the outstanding 1RTT.

A sentence saying you have to start it when completing the handshake, if
1RTT data is outstanding, would solve the problem. Perhaps I'm missing
something more obvious?