Re: [quicwg/base-drafts] SHOULD implement adaptive packet threshold loss detection (#3571)

Jana Iyengar <> Fri, 10 April 2020 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A7AF3A190C for <>; Thu, 9 Apr 2020 18:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.863
X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 jrhWu5Tu_LuO for <>; Thu, 9 Apr 2020 18:09:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25ACB3A18AC for <>; Thu, 9 Apr 2020 18:09:08 -0700 (PDT)
Date: Thu, 09 Apr 2020 18:09:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1586480947; bh=hdAALtHD7oX1IX+b+ebvrtasBSD3GvyEYx/90AeI53k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=k5weNGlxGq6fgbaVwq8Fiy2KY06Tf9QaQn54oK193c77nzF6zak/YUjBpT4eREnjO Gdkfl6TfL/AEsXgMWhVnM2gFq//ZkawBW/916N0+Q3RbENtjKgkhLiZMpktu2p7/d3 ddgQJGhX/viSYYO0fcVSRbBoYIa+w2SraHiiNaAI=
From: Jana Iyengar <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3571/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] SHOULD implement adaptive packet threshold loss detection (#3571)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e8fc73358263_3b343ff9deecd96c487af"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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: Fri, 10 Apr 2020 01:09:17 -0000

I understand that this might have performance benefit that is worth exploring further.  I question the need for doing it at this late stage, given that we will find more and more things that help with performance as we gain further experience with the protocol.

RACK is currently an informational reference, meaning that it is not required reading for an implementer. This change would make it a normative reference, and we don't have such dependencies on any TCP document at the moment. (I see that F-RTO is listed as normative, but it isn't really, I'll send a PR to fix that.)

This isn't a small change because just changing a MAY to a SHOULD isn't enough. We cannot change a "MAY adapt" to a "SHOULD adapt" without saying exactly what "SHOULD adapt" means for an implementer. At a minimum, this requires changes to the text and to the pseudo-code that include a precise description and an algorithm for adapting. (The RACK draft suggests one, but again, it's not clear to me whether that one is what we should be recommending. I want to try it out for sure though.)

On TCP's experience with this: While I understand that RACK has been deployed for a few years, I don't believe we know how much improvement this specific part of it brings, especially given the DSACK dependency in TCP (Praveen can perhaps shed some light on DSACK deployment at clients, but ... this isn't my central argument.). If there is public information about this, I would love to look at it to have a better understanding.

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