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

Marten Seemann <> Mon, 11 February 2019 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28405130EDE for <>; Mon, 11 Feb 2019 07:33:46 -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 idY2lL0S2cZK for <>; Mon, 11 Feb 2019 07:33:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C0A71271FF for <>; Mon, 11 Feb 2019 07:33:44 -0800 (PST)
Date: Mon, 11 Feb 2019 07:33:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1549899223; bh=psR7LOBJGBSE/Z8sSWIKuGT7DETq6nQHMOnCvx6C97w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LDE2DRRtV2c+Ju+V5ns315YXmr9MF1d8m0yVyCzVCEwxqk7Ky99CZWKfOn8O0chB9 b0syLdQnf69joV1zdCFiNPByFQkOFDRzgokNmPxAWutkdVG387/VkBhnIPuUpp/HEm k5tbZUojKKCaeKZmiwljaTTKhM5KxM0A9x8VwDOU=
From: Marten Seemann <>
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_5c6195d72697c_ede3febf3ad45c03232a9"; 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: Mon, 11 Feb 2019 15:33:46 -0000

I just tried to sketch the algorithm using a packet-number-space dependent `loss_time`, i.e. `loss_time[kPacketNumberSpace]`. In `SetLossDetectionTimer()`, you'd then use the smallest (non-zero) `loss_time` for your timer, and only arm the crypto retransmission timeout if all 3 `loss_time`s are 0.
This seems to work fine, and is generally (a lot) more aggressive than what we currently have, however, there's one corner case where it's less aggressive. Consider the following sequence of packets being sent:
t=1: Initial 1
t=2: Initial 2
t=3: Handshake 1
Now we receive an ACK for Initial 2, and arm the early retransmit timer at `t=1+1.125x`, where `x` is the RTT. When this timer fires, we retransmit Initial 1 as Initial 3. The crypto retransmission timeout will now be set this time plus 2 RTT, i.e. `t=1+3.125x`. This is then the first time we retransmit Handshake 1.
Without the early retransmit timer, we would have retransmitted Handshake 1 2 RTTs after sending it, i.e. at `t=3+2x`, which for all realistic RTTs would be earlier.

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