IETF Logo Mail Archive

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

Jana Iyengar <notifications@github.com> Tue, 31 March 2020 02:30 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 EB5A53A186B for <quic-issues@ietfa.amsl.com>; Mon, 30 Mar 2020 19:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.473
X-Spam-Level:
X-Spam-Status: No, score=-0.473 tagged_above=-999 required=5 tests=[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=0.726, 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: 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 xElhBttGwwoo for <quic-issues@ietfa.amsl.com>; Mon, 30 Mar 2020 19:30:10 -0700 (PDT)
Received: from out-27.smtp.github.com (out-27.smtp.github.com [192.30.252.210]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1D13A186A for <quic-issues@ietf.org>; Mon, 30 Mar 2020 19:30:10 -0700 (PDT)
Date: Mon, 30 Mar 2020 19:30:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585621809; bh=vIzhl3z3JR33yLN2F/7YvdQT+Gvr0WP5XLHwY96zXjk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gJ4iByIfE2ruwQJwmFobOe3MImGlNBDEfQlS0ByZtfwGjNNgX2gjXNApDT7eJzjJ/ NYkqegPExT22WyDdz1Oi5bjPW/cSxfoNmpKthJDmLB97IL3UJS5gT2EuS/smXM5EdL nRv99NLwfgE67iQDztGHu63M6Js8U2ju8QOagiXA=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK52Z6UEI5STPCO3PKN4R2GDDEVBNHHCF233TE@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/606361195@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_5e82ab31c0cf9_3add3fa9704cd96c1740f3"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/GK-f21RA7FbKXRPTamlCNj_7tW0>
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: Tue, 31 Mar 2020 02:30:12 -0000

I agree with @martinthomson on the principle of not requiring the enclosing packet's packet number during frame handling, and we use sequence numbers within frames to help with reordering. This was at least true in an earlier version of NCID frames, and we had discussed this principle then. This is also why the ACK_FREQUENCY frame in https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 includes a sequence number.

That said, I don't understand the issue with key updates here. Largest acked so far is a connection-level state variable that can be used for key updates. I suspect that I'm not understanding the example scenario. @martinthomson, can you elaborate on your key update example?

@ianswett: Is your example motivated by a receiver that does not remember the largest acked or one that does not wish to ack anything but the packet that was just received?

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

v2.23.0 | Report a Bug | By Email