IETF Logo Mail Archive

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

Martin Thomson <notifications@github.com> Mon, 30 March 2020 00:46 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 EA37C3A1107 for <quic-issues@ietfa.amsl.com>; Sun, 29 Mar 2020 17:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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_20=0.7, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 vxMJ0NPYRECg for <quic-issues@ietfa.amsl.com>; Sun, 29 Mar 2020 17:46:15 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879FC3A1106 for <quic-issues@ietf.org>; Sun, 29 Mar 2020 17:46:15 -0700 (PDT)
Date: Sun, 29 Mar 2020 17:46:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585529174; bh=tjLhLrkIBoCHVOoPt0QAg44+Sra9EpqTkxb+ITaMLXo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xuaMV0p2bMpKItF/I75QHiGq/ReAgBo2lDkP/NJnXjsoDYEenmnhTySAPt6WYqtSD 6dV/v/VpZl4ie20pBqg0p7cvipeVpWNo5/9tXSX5OBigF8OD486REz6A7TR5mvUha7 E9i/0Te4p74l9TridHITEFtOOU7umrzETuTBaXD0=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6ODDDXWVSFPIKXH6V4RURFLEVBNHHCF233TE@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/605729159@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_5e814155e7001_1e643fcfc60cd96c524f5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/XJptvEcaNLLyGqGucE0kDI7L0Xw>
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, 30 Mar 2020 00:46:17 -0000

I don't think we really need to cater for retransmitted ACK frames in any way.  What I'm concerned about is reordering.

Yes, using the increase of largest acknowledged as a proxy for strict ordering is a little weird, but the assumption is that frame handling is distinct from packet handling and packet numbers are not available when frames are handled.  (I think that's the principle we agreed on; that's why it's OK to use packet numbers in key updates, for example, something that I can confirm is borne out by implementation experience.)

The case you describe here has the appearance of exactly that type of reordering if the two senders also generate their own ACK frames (though this seems very strange).  But I think that the consequences of that sort of design are not our responsibility to deal with.

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

v2.23.0 | Report a Bug | By Email