Re: [quicwg/base-drafts] Fix handling of Retry in recovery (#3148)

Jana Iyengar <notifications@github.com> Wed, 30 October 2019 00:14 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 D46CB120096 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 17:14:51 -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 SMkdw-PcQvRF for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 17:14:50 -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 F1CE412008B for <quic-issues@ietf.org>; Tue, 29 Oct 2019 17:14:49 -0700 (PDT)
Date: Tue, 29 Oct 2019 17:14:49 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572394489; bh=HcfVsrOURa1CVmb5KpiNA247kqEabBgdYHsVOPkoaIM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gEtuWyiTL0jJXGGw16+id7AEn1c9KGEFOv4DBCcsh0QCfrdHHkFl5jUtFMJYoNGly kRX7gbln9l4QI7oLRS2/apVjQl04Njzc6IjA7M0m/M6Al6gBDvnjYf90qEq/4kxUHG jI1t1u0Yq31+nytheFlUR/AbRV3FiDAGDtNXGgYQ=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3WIRAPYFZDWL3N3RN3YYLITEVBNHHB476S7Q@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3148/review/308906227@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3148@github.com>
References: <quicwg/base-drafts/pull/3148@github.com>
Subject: Re: [quicwg/base-drafts] Fix handling of Retry in recovery (#3148)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db8d5f91361c_12353f85914cd960956c2"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/_RKtAkeVllTzlnzVj6jUJO89Slk>
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: Wed, 30 Oct 2019 00:14:52 -0000

janaiyengar commented on this pull request.



> +## Handling Retry Packets
+
+A Retry packet causes a client to send another Initial packet, effectively
+restarting the connection process.  A Retry packet indicates that the Initial
+was received, but not processed.  A Retry packet cannot be treated as an
+acknowledgment.
+
+Clients that receive a Retry packet reset congestion control and loss recovery
+state, including resetting any pending timers.  Other connection state, in
+particular cryptographic handshake messages, is retained; see Section 17.2.5 of
+{{QUIC-TRANSPORT}}.
+
+The client MAY compute an RTT estimate to the server as the time period from
+when the first Initial was sent to when a Retry or a Version Negotiation packet
+is received.  The client MAY use this value in place of its default for the
+initial RTT estimate.

@mikkelfj's point, IIUC, is that connection ID based routing within your server infrastructure could route your new Initial to a server that is far off. I think this is a legitimate use case, but using this sample as the initial RTT value is fine I'd argue, even if it is wrong some times. It is not expected to be the common case, and you replace it in the RTT estimate with the first actual measured value anyways.

-- 
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/3148#discussion_r340383833