Re: [quicwg/base-drafts] loss recovery of crypto packets is less aggressive, not more aggressive (#2435)

ianswett <> Thu, 21 February 2019 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4D80131084 for <>; Thu, 21 Feb 2019 06:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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_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 jlqX6HWAjGnC for <>; Thu, 21 Feb 2019 06:41:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8BE5131017 for <>; Thu, 21 Feb 2019 06:41:05 -0800 (PST)
Date: Thu, 21 Feb 2019 06:41:04 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1550760064; bh=Qx52mt7N9B/N9FvvNJmUBNIkExHPs3i3FU3ys9AMako=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=srLlB0EpAe1mZFXeTLYVs0zx9BD/sPQD3oHSc6L0jtGMr6thVUy0fMOWban0nHQL4 oT9vNI87ERkndXISvguHe/XTsE8LwCSdWYQqggXcWx+WYyj/tr6zPpDVdxl2O0xtO5 rflexToKhzPSSMIXv+Z0rmCsM91FkuEjRuQNFYvE=
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2435/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] loss recovery of crypto packets is less aggressive, not more aggressive (#2435)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c6eb88054bee_36e33f869bad45c48280b2"; 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, 21 Feb 2019 14:41:15 -0000

@marten-seemann I'll reopen this issue while we discuss this.

I believe the original core of this issue was that when early retransmit was at play, crypto retransmission was substantially less aggressive than other packets.  As you noted, that clearly was not the intent and I believe that's been fixed.

The case you outline is interesting, because even if Initial 3 is acked, the only mechanism we have to recover from the loss of Handshake 1 is the crypto timer.  If we'd like to avoid always spuriously retransmitting Handshake 1 in this scenario, we have to wait until Initial 3 is acked, because otherwise the peer likely doesn't have keys to decrypt Handshake 1.

In practice, when Initial 3 is acked, the server can likely assume the client has the handshake keys and if it doesn't receive an ACK for Handshake 1 in a relatively short period of time(maybe 1/8 RTT), then retransmit Handshake 1.  But that's making assumptions about key availability from recovery information, which seems like a very questionable optimization to save 7/8 RTT in an edge case where two packets from two different packet number spaces are lost in short sequence.

TLDR: I think the current algorithms are good, and only if we were ok with spuriously retransmitting all handshake data in the majority of cases when a single Initial packet was lost could we adopt a more aggressive approach.

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