[quicwg/base-drafts] Define how an "out of order" packet is detected (#3347)

Jana Iyengar <notifications@github.com> Wed, 15 January 2020 01:58 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 A25AF12006D for <quic-issues@ietfa.amsl.com>; Tue, 14 Jan 2020 17:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 mqYrbPijK8bx for <quic-issues@ietfa.amsl.com>; Tue, 14 Jan 2020 17:58:32 -0800 (PST)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB0F120020 for <quic-issues@ietf.org>; Tue, 14 Jan 2020 17:58:31 -0800 (PST)
Received: from github-lowworker-d31a065.va3-iad.github.net (github-lowworker-d31a065.va3-iad.github.net [10.48.17.70]) by smtp.github.com (Postfix) with ESMTP id 3B392660769 for <quic-issues@ietf.org>; Tue, 14 Jan 2020 17:58:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579053511; bh=iO+tJ+n7jWqELBPb44fWiRksu7NcvVeybrQRHpkgqq0=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=rYEgCSyftLmmV0ju8na7no9UStxFYFpQz/HtNPqUlaSMmRokp0+nFDnfT+7zizKDy e84PTndKwP9OcezKBpw8xEs2twXHoNd4jloenD4b871g9hYmHh4SAX1KHQCuN9aO3+ 4sQ8C93O1ps2h3mmR/zHwiVxfznSz9YyeZof7xGE=
Date: Tue, 14 Jan 2020 17:58:31 -0800
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6X6C5M47556KALKYN4FOSEPEVBNHHCBRY4PA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3347@github.com>
Subject: [quicwg/base-drafts] Define how an "out of order" packet is detected (#3347)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1e71c72bd67_87f3fec0fecd96c59625"; 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/3WK07kQU6HaSjqqsEVPyQMm02Xk>
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, 15 Jan 2020 01:58:33 -0000

[Section 13.2.1 of the transport draft](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-13.2.1-3) currently states:
```
     In order to assist loss detection at the sender, an endpoint SHOULD send an ACK
     frame immediately on receiving an ack-eliciting packet that is out of order.
```
@kazuho notes that nowhere do we define precisely how a receiver might do this detection. Specifically a receiver could implement this as when a newly received packet is smaller than the largest acked, or as when the packet is larger than largest acked plus one. Doing the former would actually not help with loss detection, since the receiver would not ack immediately on a gap. We should add some text codifying the latter.

-- 
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/3347