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

ianswett <notifications@github.com> Mon, 23 March 2020 18:17 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 9AC193A0A54 for <quic-issues@ietfa.amsl.com>; Mon, 23 Mar 2020 11:17:41 -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 wTXy3Z_BWO3T for <quic-issues@ietfa.amsl.com>; Mon, 23 Mar 2020 11:17:39 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64243A0CFF for <quic-issues@ietf.org>; Mon, 23 Mar 2020 11:17:39 -0700 (PDT)
Received: from github-lowworker-5825cd4.ac4-iad.github.net (github-lowworker-5825cd4.ac4-iad.github.net [10.52.22.68]) by smtp.github.com (Postfix) with ESMTP id CB4286A01F8 for <quic-issues@ietf.org>; Mon, 23 Mar 2020 11:17:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584987458; bh=cdiJmKs4syi/IZgCKKvZ3fi+f4PxujmN2wmsJl6oYRA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Tmw2zH8BthB4dmc6mTqroL/3PRpHCzIu4hiiB3XAHppEYPBfz/yGPB0eigx0lAj5j yr/jJYog7M5/Iu0YhVUCDA4udPcOVyTsCWN4KukzSd2r0+5+wemis1dru8Q6SmG+XE UkQKaU3eu+/yAZx44F80G9ohvTHLEzv7bf1EGN5w=
Date: Mon, 23 Mar 2020 11:17:38 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4OH6FQCEL3XXOI2YN4QTPEFEVBNHHCF233TE@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/602772028@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_5e78fd42ba190_2e583f92184cd9684493b"; 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-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/-MNXcynPbXoVcgSOA2Y9wxnaxDU>
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: Mon, 23 Mar 2020 18:18:05 -0000

For out of order ACK frames, you can use the packet number the ACK arrives in.  I realize that we have tried to allow frames to be retransmitted, but I think retransmitting ACK frames without modifying the ACK delay/etc is so harmful we should probably prohibit that one frame from being retransmitted, since it creates a bunch of edge cases.  Or we could let ECN validation could fail, but that'd be a bit sad.

I'm confused about what the issue with key updates is?  The largest acked you've ever seen doesn't change, just the largest acked from the last ACK frame.  When determining the size of the packet number, we say: "The sender MUST use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent."

I'd rather not make this a MUST unless we have a good reason.  There are valid use cases that become more complex with this constraint.

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