Re: [quicwg/base-drafts] Prioritize Handshake probe packet over Short packet (#3583)

ianswett <> Thu, 23 April 2020 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 892283A0B99 for <>; Thu, 23 Apr 2020 13:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Status: No, score=-1.696 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 knAHgncKkAH3 for <>; Thu, 23 Apr 2020 13:04:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AF993A0B8D for <>; Thu, 23 Apr 2020 13:04:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF10A282C3B for <>; Thu, 23 Apr 2020 13:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1587672275; bh=/zDNahNLdSwCpcVIKyUF+p9vHmXnBBhYgxXoJjSB2s4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Onu7UYkR8LO8wIneb/LgGB/xTrGgerXITHNUY9CunqaJV8KT/JiJB7mq3+LmyJ9CW eZeaurusJ8PUgezN9/A7mkqWo4kHQXBqEM2blIgSsIzlUrbLb+dcig6BNnp8MKybER Tr4hmUdocnh14QyXUFkRyGqWEaffsvPClDNNiPHI=
Date: Thu, 23 Apr 2020 13:04:35 -0700
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3583/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Prioritize Handshake probe packet over Short packet (#3583)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ea1f4d3ded37_79403ffcf22cd95c22442ea"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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: Thu, 23 Apr 2020 20:04:41 -0000

In this case, I believe alternating is the right thing to do, because the server either has Handshake receive keys or 1-RTT receive keys, and the client doesn't know which.  Because of HANDSHAKE_DONE, the client will eventually complete the handshake and drop the Handshake PN space as long as the client's Handshake packet(containing the finished) gets to the server.

However, this case is an excellent motivation for this text:
> In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from other packet number spaces with in-flight data, coalescing packets if possible.

This text was written prior to HANDSHAKE_DONE, but I think there may be other reasons to use handshake complete and not confirmed in this case, so I would be very hesitant to change it without a lot of consideration.

Is there a part of mozilla/neqo#448  I should focus on?  The text talks a lot about packets being marked as lost when the PTO timer fires, which makes me very confused, since QUIC doesn't mark packets as lost when the PTO fires.

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