Re: [quicwg/base-drafts] Server sends Handshake probe packet which does not attribute to any progress (#3582)

ianswett <notifications@github.com> Thu, 23 April 2020 19:48 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0C33A12C9 for <quic-issues@ietfa.amsl.com>; Thu, 23 Apr 2020 12:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Level:
X-Spam-Status: No, score=-1.482 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 LT34Pd4x5vRx for <quic-issues@ietfa.amsl.com>; Thu, 23 Apr 2020 12:48:14 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15DA3A12B7 for <quic-issues@ietf.org>; Thu, 23 Apr 2020 12:48:13 -0700 (PDT)
Received: from github-lowworker-52827f8.ash1-iad.github.net (github-lowworker-52827f8.ash1-iad.github.net [10.56.108.24]) by smtp.github.com (Postfix) with ESMTP id 95C051C0640 for <quic-issues@ietf.org>; Thu, 23 Apr 2020 12:48:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1587671292; bh=Rbfu7pB4Hg2TdgyZRO9jl30wu6tjSzwRlHqG3rC9yjo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qzApWtXi/UwFLCTW/xLY6DWqVMPJZgD25yCZe8pf47tLYQTaFy0Vp4GfsdG1RgfIU pT5mZOUVgdwWiimdj2evQUx+44W1tuVap9R63MY4/9JLdb1Uvm/ODDVabklsazSJUt 4LHTcrkXuH0nHi2bsiprE1w1WNI1nIQCuwTyZXBU=
Date: Thu, 23 Apr 2020 12:48:12 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK44BUO4DNOXSBWFGRN4VXI7ZEVBNHHCHRBAJI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3582/618624984@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3582@github.com>
References: <quicwg/base-drafts/issues/3582@github.com>
Subject: Re: [quicwg/base-drafts] Server sends Handshake probe packet which does not attribute to any progress (#3582)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ea1f0fc84dd8_30e3f8ad28cd95c4476a6"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/yQdklbidRwUW0j3EUNJgOXfOzyI>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 19:48:16 -0000

Q: I assume the server sent and the client received server_initial#0 as well in this example?

The interesting text is:
> 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 prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement.

In this case, the text says to not arm PTO for ApplicationData until handshake complete and there's nothing in flight in Initial or Handshake, so I don't believe the PTO alarms should be set, so "server resent Handshake(server_handshake#1)" would never occur.

Admittedly, this text can be hard to read(it's certainly hard to write), so if you have any editorial suggestions, that'd be welcome.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3582#issuecomment-618624984