Re: [quicwg/base-drafts] Explain asymmetric confirmation condition (#2881)

Martin Thomson <> Tue, 09 July 2019 07:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEF1D12036A for <>; Tue, 9 Jul 2019 00:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_IMAGE_ONLY_24=1.618, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A_lFnmXa_0UU for <>; Tue, 9 Jul 2019 00:44:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B46C6120364 for <>; Tue, 9 Jul 2019 00:44:07 -0700 (PDT)
Date: Tue, 09 Jul 2019 00:44:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1562658246; bh=cxl/47YB9BIxqbFOoM6vLnkk4vSloqFhQSFynxMci0o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NHmNQOPxjfTVBOHxs/Qlg8THDDb6lrhTlA1/swwEgvGN+7Cj/NhF5iis7XiiuJYDK e1I9dxwiA+2X3f1kQ1gaHM39TSvJkA8vFeakU6iuJ2YNvwL5/fTnBTvhm8bja7wwiw kwW3dDvRr1y7UxuqfxrlTogSFjqRD0z1EVcPO4qY=
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2881/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Explain asymmetric confirmation condition (#2881)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d2445c6a7bc0_75563fe2b5ccd96815675b2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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: Tue, 09 Jul 2019 07:44:10 -0000

Well, keep in mind that "recovery" for PING, which is the way you would approach this if you never had anything to send, depends on you generating a new PING with every transmission.  So it's not that terrible.

For our implementation, we would simply crank the lever and spit out another packet when the PTO fires, which would produce a packet that coalesced the missing Handshake with a 1-RTT packet.

It only gets hairy when the lost Handshake packet overflows the MTU.  Which, sadly, is possible.  If we lost more than a PMTU, it gets a little hairy, because we will probably won't send any 1-RTT packets ever.  I might be willing to let the connection time out in that case though.

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