Re: Hole in loss recovery algorithm?

Ian Swett <> Wed, 29 April 2020 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FC9D3A082A for <>; Wed, 29 Apr 2020 15:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 trvTd2_06v0K for <>; Wed, 29 Apr 2020 15:03:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DF023A0773 for <>; Wed, 29 Apr 2020 15:03:11 -0700 (PDT)
Received: by with SMTP id j1so4449527wrt.1 for <>; Wed, 29 Apr 2020 15:03:11 -0700 (PDT)
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=bx8hhqJ6ocvaJrggvp5ZflTSK3irEVQscT08RGNdM+I=; b=eP4NDNNSiJuS/z9YAz4NLLNOTiH9kmQULlqDmUxoakxhlxjibOSaErViqvbKgs58q9 RYOq3AZ41t7imwJbHUxv0KPB6/nacA6sbTaPUBAebhA6LDvajhCorM9BQbZGlCW2je1c O6b+gtClgcG+foZq/J3UA3QB5IdyvAQwdVDbufU2WvM3Yt0QFLjRja/muSl27StKLrzD HvmY8Di4KcdptARV/3JRV4DUR2srInr4ElSXIM0DlZNkKPXyReosJy7dE4UBGa5Nqfao IFWNLgVWcgiXK7jgtIN26JuoGtu/fqR/yRLA+fvEhi+mNePVAEpWmgzqDdgp7xNsKREW vWxQ==
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=bx8hhqJ6ocvaJrggvp5ZflTSK3irEVQscT08RGNdM+I=; b=PkHklirtmlwKXuLuJSPsrCcFmGTXX9Qp57+Lqq/YrdH1Gx3p1FiST+1Bc+W/r9HeyP fwuaQ30SaItGU16TK1zGaXf1Tgz2dvP7Hg3e6U85sKnoP9kcLvWkpw7HlOuLOO+TVJK1 DNwqW2TJmv+vwwtOY5n+hh8mkY+I04wMSv7DV/X4/TU5EwFVv6/i4pg0ORMUPom+si1m 0TlRsqUSBWUm/3s4iPO8c8YWnxz3L5nBtoVLREzhCoBEJ/sZPmlBvooZoVzt0L7iWlgD R2/n7597cYNcfmwb9maWQeSQVj8GgFCxdfFR2Tdl8583Tp1449hY1pyhuEWcIx9UNH/V a36A==
X-Gm-Message-State: AGi0PuY7G8EnAz6OBDjnsLuANbT55N5iet1UNO1diTV2f4vj1jG5UHo9 nu6QuK++S9BaqXKuZ4MJUyc2aMd2VBxAm9nkr1e5Dg==
X-Google-Smtp-Source: APiQypIYWsywrTOugFZavys3fSn77otfpbj/y6qc4ocPpKj43KECqX8hrNyNzDKuWdUIfowlQIyzgMUdaK4sck5iSJs=
X-Received: by 2002:adf:f34f:: with SMTP id e15mr25007wrp.275.1588197789392; Wed, 29 Apr 2020 15:03:09 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ian Swett <>
Date: Wed, 29 Apr 2020 18:02:53 -0400
Message-ID: <>
Subject: Re: Hole in loss recovery algorithm?
To: Martin Duke <>
Content-Type: multipart/alternative; boundary="000000000000126dc705a4751dda"
Archived-At: <>
X-Mailman-Version: 2.1.29
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: Wed, 29 Apr 2020 22:03:43 -0000

When the Client Finished arrives, the server is handshake complete, so it
should arm PTO for the 1RTT data, though I don't see text making that
explicit.  Should it be added here

In the psuedocode, the PTO timer is reset when a PN space(the server's
Handshake in this case) is dropped.

Also, after the Client Finished arrives, the server sends HANDSHAKE_DONE,
which would also re-arm the timer and fix the issue, but I'd rather not
rely on HANDSHAKE_DONE to solve all the problems.

On Wed, Apr 29, 2020 at 5:23 PM Martin Duke <> wrote:

> 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?