Re: [quicwg/base-drafts] Change PTO to be per packet number space (#3066)

Marten Seemann <> Mon, 04 November 2019 02:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2C2712002F for <>; Sun, 3 Nov 2019 18:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bIS2yl3KJim2 for <>; Sun, 3 Nov 2019 18:37:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0933120020 for <>; Sun, 3 Nov 2019 18:37:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E87695210FC for <>; Sun, 3 Nov 2019 18:37:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572835024; bh=vmCJpVK5QJcuaIVlh0RUaW12oKUpYGHrEjacHKsHzPw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=icfTA5IajMRr0u6oNYeU7CWqAG9JYOrrOd76Ob6HHjxUpRkIETQJYaHtzBP3MinME JBB1ydkA01+xUjb7snbLjYnsRn9q+HeRu5MqwQCAZrJTGZgCK7yb4jYS6R9D5AAWCm BiFwAbphfChO9drcrT2LjQ8eQoA2h1Y2e1WwDKkU=
Date: Sun, 03 Nov 2019 18:37:04 -0800
From: Marten Seemann <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3066/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Change PTO to be per packet number space (#3066)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dbf8ed0d67db_7eb33fbcb1acd96c42735d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 02:37:08 -0000

marten-seemann commented on this pull request.

 The PTO value MUST be set to at least kGranularity, to avoid the timer expiring
+A sender computes its PTO timer every time an ack-eliciting packet is sent.
+When ack-eliciting packets are in-flight in multiple packet number spaces,
+the timer MUST be set for the packet number space with the earliest timeout,
+except for ApplicationData, which MUST be ignored until the handshake
+completes; see Section 4.1.1 of {{QUIC-TLS}}.  Not arming the PTO for
+ApplicationData prioritizes completing the handshake and prevents the server
+from sending a 1-RTT PTO packet before it has the keys to process a 1-RTT
+packet.  This simplifies to setting the PTO on the lowest active packet number
+space if packets from two different packet number spaces are sent when the PTO

I'm not sure if I understand this sentence. Consider the server that has just sent ServerHello and it's certificate, i.e. has outstanding Initial and Handshake data.
Isn't the whole point of this PR to arm the PTO timer based on both packet number spaces?

This is what I'd imagine would happen if no ACKs from the client are received:
t = 0: send Initial, immediately afterwards send Handshake. Set PTO timer for the Initial.
t = 1: PTO timer expires for the Initial packet. Send an Initial probe packet. Now the Handshake packet sent at t = 0 is the earliest outstanding packet, so set a PTO timer (with exponential backoff) for this packet.
t = 2: PTO timer expires for the Handshake packet. Send a Handshake probe packet. Now the Initial probe packet sent at t=1 is the earliest outstanding packet. The PTO timer for this packet would expire at t=5.

Is this correct?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: