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

Mike Bishop <notifications@github.com> Wed, 01 April 2020 14:47 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6E3A107A for <quic-issues@ietfa.amsl.com>; Wed, 1 Apr 2020 07:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Level:
X-Spam-Status: No, score=-1.482 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luR5x7oLFN9m for <quic-issues@ietfa.amsl.com>; Wed, 1 Apr 2020 07:47:45 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375EE3A109B for <quic-issues@ietf.org>; Wed, 1 Apr 2020 07:47:45 -0700 (PDT)
Received: from github-lowworker-cde56e0.va3-iad.github.net (github-lowworker-cde56e0.va3-iad.github.net [10.48.25.52]) by smtp.github.com (Postfix) with ESMTP id 9CBDE5209E6 for <quic-issues@ietf.org>; Wed, 1 Apr 2020 07:47:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585752463; bh=kDhMrVkaP1rpuyyB+bJAllsVWEoXcvzEtm+oq0A/nx8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=T50KMOO1XOV+KJFZjdTcOQ9CKs6vFn38E6o/LOLsOCl7bQcp0mwgp2AaLxzdpbPNd zTu88kuSyGVyoplns6wHaoNE2J004sVqsKwqDNl5+epsJPhZvcIWIk99vUYgfmX0iy zyzXKLbsHg+2SkGedSY6xxrlSAqQAnnki1fuisp4=
Date: Wed, 01 Apr 2020 07:47:43 -0700
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5TJZDMXCQCEY2SAEF4SCFI7EVBNHHCF233TE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3541/607293498@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3541@github.com>
References: <quicwg/base-drafts/issues/3541@github.com>
Subject: Re: [quicwg/base-drafts] Retaining the largest received packet number (#3541)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e84a98f8de81_d6b3fd39c6cd964919b8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/F7rpdAMoYjh7ZT64zTh2QytGUMA>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 14:47:49 -0000

> 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:

Perhaps it's a naive model, but I had envisioned an implementation remembering a chain of ranges of packet numbers it had received or not.  The implementation would save space by forgetting the earliest packet numbers when the chain got too long, and would construct an ACK frame out of the latest set of these ranges it had room for.

In that mental model, at least, there's not really room for the idea that you might drop the largest-acked frame number from your memory because it's too old -- it's always at the most-recent end of your chain, even if you currently happen to be receiving packets that fill in the middle for some implementation-specific reason.  (Implementation-specific *to the peer*, which you obviously can't know about or code for!)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3541#issuecomment-607293498