Re: [quicwg/base-drafts] Retaining the largest received packet number (#3541)

ianswett <> Fri, 27 March 2020 12:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC0673A05A4 for <>; Fri, 27 Mar 2020 05:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.695
X-Spam-Status: No, score=-1.695 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, 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, URIBL_BLOCKED=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 83Y24BLk8sSS for <>; Fri, 27 Mar 2020 05:55:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B5AF3A00AE for <>; Fri, 27 Mar 2020 05:55:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF4A45200EE for <>; Fri, 27 Mar 2020 05:55:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585313707; bh=rW2ISGAkp7VaxERwvZFA4sm0z+xRSgGQHnTvO/fYv+4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=L7HGkAgcHnZ9GLtc8HNJmkEHcB8x18XmI2PJ2IRyo6a5+IqF8zQGdDrxEfECFvpKP SPo+8RtBctPC85zbyzMvrkvXQxkpGi13OKt0/D+rKeO7Hs3sCPK2Sv1cyJz22FR2+f eAxcl6zXSQbIo2VmIN9oS83WRumyhaBd8yqkvh0E=
Date: Fri, 27 Mar 2020 05:55:07 -0700
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3541/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Retaining the largest received packet number (#3541)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7df7abbf373_363d3fdfd20cd9641037f"; 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: Fri, 27 Mar 2020 12:55:12 -0000

I'd like to suggest tracking largest acknowledged from forcing all ACK frames to contain the largest acknowledged and have that value never decrease.

Given you need to track largest acknowledged locally(ie: not only in the in-flight ACK frame), I don't think there are any problems there.

I have two cases in mind where the largest acked could validly decrease:
1) A receiver that tracks a limited number of ACK blocks and the oldest block happens to be the one containing largest acked.
2) If an application was reordering tolerant(ie: from then two different senders on a single 'connection' may be sending packets with disparate packet numbers, causing what appears to be very large scale reordering.  In this case, it'd be valuable to discard the older ACK ranges even if they contained the largest acked.

Maybe the first is an edge case we don't care about in a use case we aren't optimizing for and the latter is solvable with careful issuing of packet number ranges.  Even so, I'm not sure what the motivation is for this change?  I guess the ECN case could be, but using largest acked as a proxy for retransmitted ACKs is a very bad design in my opinion.

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