IETF Logo Mail Archive

Re: [quicwg/base-drafts] Review conditions for PTO arming around end of handshake (#3613)

ianswett <notifications@github.com> Mon, 18 May 2020 10:41 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 3CB1F3A0AA6 for <quic-issues@ietfa.amsl.com>; Mon, 18 May 2020 03:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.081
X-Spam-Level:
X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[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.282, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-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 (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 hWsSsuFJK6dV for <quic-issues@ietfa.amsl.com>; Mon, 18 May 2020 03:41:21 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D603A0AA3 for <quic-issues@ietf.org>; Mon, 18 May 2020 03:41:20 -0700 (PDT)
Received: from github-lowworker-1dbcc59.ash1-iad.github.net (github-lowworker-1dbcc59.ash1-iad.github.net [10.56.105.54]) by smtp.github.com (Postfix) with ESMTP id 3430A1C11BE for <quic-issues@ietf.org>; Mon, 18 May 2020 03:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1589798480; bh=3wPduvRCcl/3N7bm1hirspXWvbaCMf7XUgl6yWVfOmM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Yl5P5kHhljE2mdcshKvpR6qPRxAKYWbvzexowzo975v7A2N6Y76jjnFw20acegOLK 85q80X/DjeDP9IUz3A7XYjayOyYWg881uUWwf1gihDJ+qqLHJjmEyyUe8ViiIyhJkw ZrCOhSh6tamBD5ASxuTDjh+FKdNkFa/5e8D1jNGk=
Date: Mon, 18 May 2020 03:41:20 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4YRWPGTWAY344GROV4ZZDVBEVBNHHCIVAFGY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3613/630099015@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3613@github.com>
References: <quicwg/base-drafts/issues/3613@github.com>
Subject: Re: [quicwg/base-drafts] Review conditions for PTO arming around end of handshake (#3613)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ec266505e1f_1e223fdb628cd96c11448"; 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/1qYXJLDoT0sGYL2h8Ma17qbbqac>
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: Mon, 18 May 2020 10:41:22 -0000

The PTO is always armed when there are bytes in flight(except when the loss timer is armed), it's just a matter of what PN spaces it can be armed for at a given point in time.  Once the connection is handshake complete, it's immediately allowed to arm it for inflight 1-RTT ack-eliciting packets.

Re-reading the text, I couldn't find anything explicitly calling out that the alarm may need to be recomputed and reset in the handshake confirmed case, though it is stated for discarding keys.

As clarified in #3597 when the client is handshake complete but not confirmed, it is unsure whether the server has Handshake keys or ApplicationData keys, but it's very unlikely to have both.  As such, sending something ack-eliciting from both PN spaces is safest.

-- 
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/3613#issuecomment-630099015

v2.23.0 | Report a Bug | By Email