Re: [quicwg/base-drafts] Retransmit server initial upon second Initial (#3080)

Kazuho Oku <notifications@github.com> Tue, 29 October 2019 00:55 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 75A8B1200C7 for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 17:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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: 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 xZkps1ZifAed for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 17:55:48 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF213120047 for <quic-issues@ietf.org>; Mon, 28 Oct 2019 17:55:47 -0700 (PDT)
Received: from github-lowworker-275fa97.va3-iad.github.net (github-lowworker-275fa97.va3-iad.github.net [10.48.17.64]) by smtp.github.com (Postfix) with ESMTP id F04788C03B2 for <quic-issues@ietf.org>; Mon, 28 Oct 2019 17:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572310546; bh=XtyMElgLEsKW1fs//+Bo+b8QXIXR+vzR2tp3sso008I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=b/OiJnKNC+bzBhnKkh0a8uK2LsPlZDhVUuiOxNUPfYLd8BIH9q/CL9VK4mZ9sPBei DzKpyvGrwf/MrurBbu0x2gnWwEXJ/KJ48k7HEfDP7J8GUQSchyfnCgJWq2Ubj8cBbN hZqJ0TR/gLbqC0HVQrbcczVmaNIB2T4yNPbsyVFY=
Date: Mon, 28 Oct 2019 17:55:46 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5T63U5NO52GZISSV53YTAJFEVBNHHB37QS2E@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3080/review/308223551@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3080@github.com>
References: <quicwg/base-drafts/pull/3080@github.com>
Subject: Re: [quicwg/base-drafts] Retransmit server initial upon second Initial (#3080)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db78e12e077c_5223fc4872cd964780c4"; 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/OLoudxvdrpuNUDRlwilBjvnMEcg>
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, 29 Oct 2019 00:55:50 -0000

kazuho commented on this pull request.



> @@ -519,6 +519,26 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake packets prior to obtaining Handshake
+keys it may assume some or all of the server's Initial packets were lost.

As there's a chance where a client receives an 1-RTT packet before it receives Initial and Handshake packets, I think it'd be more natural to cover that case too.

Maybe s/When a client receives Handshake packets/When a client receives Handshake or 1-RTT packets/.

> @@ -519,6 +519,26 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake packets prior to obtaining Handshake
+keys it may assume some or all of the server's Initial packets were lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as
+though the PTO expired. A client MAY send an ack-eliciting packet with no
+CRYPTO data if all Initial data has been acknowledged.  The PTO can only be
+shortened once in this way. Subsequently, the PTO uses the normal calculation
+with exponential backoff.

Am I correct in assuming that this way of setting the PTO is to be used *only until* an endpoint learns the RTT?

Consider the case where the server sends three datagrams (Initial1(CRYPTO+ACK), Initial2(CRYPTO), Handshake1(CRYPTO)) as its first flight. When Initial2 gets dropped but other packets are received by the client, the client would have an RTT estimate (as it processes the ACK in Initial1), but also have an undecryptable Handshake packet too, which this section discusses about.

My intuition is that the provision of this paragraph should not be invoked in such a case, as RTT has already been learnt.

If that is the case, it might be a good idea to clarify that the section is about estimating PTO until an RTT estimation is obtained.

-- 
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/pull/3080#pullrequestreview-308223551