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

ianswett <> Mon, 11 February 2019 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C1A413105F for <>; Mon, 11 Feb 2019 08:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Status: No, score=-3.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_NONE=-0.0001, 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 YNH7_DqBKa1u for <>; Mon, 11 Feb 2019 08:09:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6B7D130E9C for <>; Mon, 11 Feb 2019 08:09:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=ci5yaugM6SVlQnLyZ7ad1WgZ9LU=; b=m71optxXhe9ZnL1E Nm7XG5GhnZe3FcwRNKSE+pA3LGzF1mXoyB6mE2zKwn4t5DXmq39OOZb8U+V8zEkm vB9PmZuyQaEWPkdJ9c7L2Ei5fIrVFe6WIJ3SvuKy9t+PxeJY0W9mYqT2ka1qbSEf lZ+ost9ikip1ASDODDAY91/Y6y8=
Received: by with SMTP id filter1350p1mdw1-6951-5C619E32-44 2019-02-11 16:09:22.772879069 +0000 UTC m=+501359.140858071
Received: from (unknown []) by (SG) with ESMTP id xIBOa8jHRVyazveF-h_eWA for <>; Mon, 11 Feb 2019 16:09:22.809 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id BED002C009D for <>; Mon, 11 Feb 2019 08:09:22 -0800 (PST)
Date: Mon, 11 Feb 2019 16:09:22 +0000
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_5c619e32bd0b6_35453fb6e4ed45c45365c4"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak09Lx+gEo3y4ULZkRkpsJji98OotsL+hB3CJw jB1V58gybzsTNXsd0803XRXIfTP6MTHVZaSrE30nbYhn7XfmbtpVeldO393vUa5bitg4Y+orN8upq6 rNGBT7EbVADdLnMsYqFp9Ohr4nNVoLEVmnkVUyYIg7shbv7KBdQRppGHrw==
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 16:09:27 -0000

Good point, that is a case when the new approach is slightly less aggressive.

If we wanted to favor aggressiveness during the handshake, we could arm the crypto timer based on the left edge(earliest unacked ack-eliciting packet) rather than the right(latest unacked).  That's a larger change than I'd like to make in this CL/issue, though.

I believe the example you outlined above is fairly unlikely, because for most connections, if multiple initials are sent, they're likely to be re-transmissions, not new data.  In that case, when Initial 2 is acked, Initial 1 is immediately lost and Handshake 1 is still the only outstanding ack-eliciting packet.  That being said, I can probably construct other situations that are somewhat similar.

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