Re: [quicwg/base-drafts] Behavior around key availability delays during handshake (#3874)

ianswett <> Thu, 20 August 2020 13:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F00C3A0ABD for <>; Thu, 20 Aug 2020 06:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Status: No, score=-1.483 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DGbXoFF4p4a9 for <>; Thu, 20 Aug 2020 06:55:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 961753A09C0 for <>; Thu, 20 Aug 2020 06:55:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DAE5C600DED for <>; Thu, 20 Aug 2020 06:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1597931717; bh=MpadtD6HJNCUt8vACjCDYzhet4EpbkiDv530qA4yiX0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zMenT88OJy40tHxs3/RXGi35jPiFfDebBflaZBJR7baHnvKHmW28vV0a7Tnjkc0to ikOtVYb+yGNALBYo7VtXl2d4NquISHlqdZrlvRSVxmTtE9EuM0TJEhOVP5kGjrgzew Cn4zxQ076Nwx/u42k5tClxHdrY/qW/IZIB6tfEwM=
Date: Thu, 20 Aug 2020 06:55:17 -0700
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3874/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Behavior around key availability delays during handshake (#3874)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f3e80c5ca90a_d95196411984a"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Aug 2020 13:55:20 -0000

@ianswett commented on this pull request.

> @@ -348,6 +348,13 @@ acknowledgement delays are likely to be non-repeating and limited to the
 handshake. The endpoint can therefore use them without limiting them to the
 max_ack_delay, avoiding unnecessary inflation of the RTT estimate.
+Note however that a large acknowledgement delay can result in a substantially
+inflated smoothed_rtt, if there is either an error in the peer's reporting of
+the acknowledgement delay or in the endpoint's min_rtt estimate.  Therefore,
+prior to handshake confirmation, an endpoint can ignore RTT samples if adjusting

Is this better as a MAY?  We never say you can ignore RTT samples in any other circumstance, so this feels a bit new.
prior to handshake confirmation, an endpoint MAY ignore RTT samples if adjusting

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: