Re: [quicwg/base-drafts] PTO after handshake completion is not well-defined (#3831)

Kazuho Oku <notifications@github.com> Tue, 07 July 2020 21:38 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 BBB553A0AF4 for <quic-issues@ietfa.amsl.com>; Tue, 7 Jul 2020 14:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 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, 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 r4Qt3PmcyUeb for <quic-issues@ietfa.amsl.com>; Tue, 7 Jul 2020 14:37:59 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC323A0AF3 for <quic-issues@ietf.org>; Tue, 7 Jul 2020 14:37:58 -0700 (PDT)
Received: from github-lowworker-c53a806.ac4-iad.github.net (github-lowworker-c53a806.ac4-iad.github.net [10.52.23.45]) by smtp.github.com (Postfix) with ESMTP id A8ACD6A0068 for <quic-issues@ietf.org>; Tue, 7 Jul 2020 14:37:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1594157877; bh=S5yPHhtz2SBs4Z+o+z/uw3N+zQDjEq160SOAHOtdhbg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=v6wSlfkGpzXEkBQgPzUt6Un/rx+rCmVmhJvlqmVIi2g210u+tbu3jYEBxynlQYLep lQoe98eUmBNMb8iB0Ip46vjwBL8CDioPXS2ger/ToA0PpuEQTnvfovas70cCgxyG4K bLQxSSNPIUd2B1JgcHbS5wlruyHxr7m6X9rxnps4=
Date: Tue, 07 Jul 2020 14:37:57 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZWW22NX5QBIV7LYCV5CDGDLEVBNHHCNXO66A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3831/655149228@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3831@github.com>
References: <quicwg/base-drafts/issues/3831@github.com>
Subject: Re: [quicwg/base-drafts] PTO after handshake completion is not well-defined (#3831)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f04eb3597f60_58f73ff3c40cd9681722f2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/J1VBK8wqzR73XTMB6_ILiZrxaT4>
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: Tue, 07 Jul 2020 21:38:01 -0000

IIUC, what needs to be applied is the latter. The former is merely pointing out that pto_timeout is defined as the minimum of `time_of_last_ack_eliciting_packet[space] + duration` among all the PN spaces, and therefore that it needs to be recalculated when PN spaces are discarded.

> For example, if the entire first flight is lost, the server won't retransmit the Initial for 1s. When the handshake then completes, the RTT is most likely << 1s, which would mean that the timer is set to a time in the past, if we base it on the time the 0.5-RTT packet was sent.

Generally speaking, I think that this is the correct behavior. If an endpoint has sent a tail, and has not received an ACK for more than 1 RTT + alpha from the moment it sent the packet, it is natural to assume that the packet might have been lost. There is no problem in the endpoint realizing that it should send a probe immediately, when the quality of the RTT estimate improves.

That said, I do see problem with sending a PTO when the peer is possibly stuck in calculating the traffic keys; see #3821.

-- 
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/3831#issuecomment-655149228