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

Marten Seemann <> Tue, 09 July 2019 07:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 066A1120380 for <>; Tue, 9 Jul 2019 00:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ei59BMExeVpx for <>; Tue, 9 Jul 2019 00:57:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09AEA12010C for <>; Tue, 9 Jul 2019 00:57:56 -0700 (PDT)
Date: Tue, 09 Jul 2019 00:57:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1562659074; bh=k3E0WJL9098eWsgC1Hv8F54mrGM0X9M6vOPlOqFh9v4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=KAvZnXsdFTzUzC45UoakN44BpZ8TTl5y+dO2/KniyMxKH1dPFzdxOsYQdHpE9Hzwg 0dBpHn2W13Cjtqnktv6iXzPCPlhVfSUm7BmXrDE6sAoKDxMYLNTuUBIeXhft6jvkLa HDkKaU13fMnXJhnmzKNCqSCVWgoTzcq3DvzcBK5g=
From: Marten Seemann <>
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_5d244902c6f0c_58f93f81918cd96020880ec"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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:57:58 -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.

If I understand your point correctly, you would either need to change `    RetransmitUnackedCryptoData()` into `RetransmitUnackedCryptoDataAndAtLeastOne1RTTPacket()` or `RetransmitUnackedCryptoDataAndSend1RTTPing()`. That sounds doable, but it gets complicated when you take the congestion controller into account: It could happen that you have enough cwnd to send the retransmissions for the Handshake packets, but not for the 1-RTT packet. What you really want is to send the retransmission for the 1-RTT packet as a probe packet (i.e. never blocked by congestion control).

> I might be willing to let the connection time out in that case though.

I don't think timing out is acceptable in the case where just 2 packets are lost. In my opinion, the only case where a timeout is justifiable is if the connection is (effectively) blackholed.

You can see the root cause of #2863 as not a problem with loss recovery at all, but with our definition of "handshake confirmed": The server is dropping the keys too early. If the server kept the keys for longer, this loss pattern would harm the connection at all.

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