draft-smith-quic-receive-ts and packet reordering

Chris Box <chris.box.ietf@gmail.com> Wed, 19 March 2025 08:16 UTC

Return-Path: <chris.box.ietf@gmail.com>
X-Original-To: quic@mail2.ietf.org
Delivered-To: quic@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id CAD9AE88D06 for <quic@mail2.ietf.org>; Wed, 19 Mar 2025 01:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p8RJpwDP0h7 for <quic@mail2.ietf.org>; Wed, 19 Mar 2025 01:16:18 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D1DB7E889AE for <quic@ietf.org>; Wed, 19 Mar 2025 01:16:05 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-aaeec07b705so1022204966b.2 for <quic@ietf.org>; Wed, 19 Mar 2025 01:16:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742372165; x=1742976965; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y5okzrn0000pLqHg6S7kgjNuTOb0utVERd7blgUjeUo=; b=lpkWRw7gJ4faRnYj8JHOMio0kPA7js5dsds58Ox8xraTgBKBGCN27brOQmo6Xge+di cTqfuXab5FS46irHJIkh0aycvDvxZF+dHTu11oWCQ1Y01Rca6CFfvHS0E6tbz6EicJmv 0f0zY4mellw+tTmeKbJLblSy4Hx2N9oD4wsvehoHdP26JJtDIEpZWYpojBC+yjJGVlYw DcmIZX4EzYvCCq28qvV+Q9CsxJuwZaBt0UBucnE2b4ZKUTiRoxlUzbcCf92fdRjATkTH MH5z8oEbDhQ3tXEWquahjK+aPumQ18oAM9kEir0mKQSA7qaEc6o3yzVDxRNLtClbGehM wxrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742372165; x=1742976965; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y5okzrn0000pLqHg6S7kgjNuTOb0utVERd7blgUjeUo=; b=SVDigLgCf6CsDRrNrw5Puv7WMmup8Ng4MQ7YMuwj5HVFAjCkhutWKhfmAFAUcin5hT VCOsrbrL24t9R9yOe00ohiml6Ujm3vcAvCPu8uI/JKtxhnSIk9UbQ7pJwU4x3iHcTQBZ QRgIyEcPOBDPXBhojtTks6RBZLWhjRrI4nVENac3XIATZvhz/nG97KdoxM1o9G6QwhHI l9HFlSPkIw/FXFnT43UPRbYnNPR/i+25ACU1T2O2Gvpo+POssIlI66Sa1Ta+1Ri5KyWU CgpCulbopTiEk1/uBL16ZSmIoQgXFMazUJ+W5/z9SqUL4l+E5WPK8cEgZ0ff8uWHl1fJ TVtg==
X-Gm-Message-State: AOJu0YxQD4iGNZnN6f/yqJ5sG5Ca6pcgc+2zxT8Rkxjns1lX3djwGAts mNBfGtkP1fUgb8+syX69HXsa0OFTo2t9NvyNbxKY8MDBk1f/tKkc5UiNpRM1YiSwlvObcpb/aSJ EaE7UsErecSvMnqheVbhUPJG7IV8ExvlBmWk=
X-Gm-Gg: ASbGncttMYLV9qY+hoa0gSJYKE8NwGuK8h+JB8FXPXRK1P6Z+12SBiXaIlYYYce3Zao yHz64iir2KEXIPqKQcKhzUCMG6ifK1S/QwEhfbbj2P9rPXIt8cTGDthjh+oMKYjtopeOEM6D6u+ IeEpqNd1JdD256Pvi2HIDKNv72LNONFwJqmiE=
X-Google-Smtp-Source: AGHT+IGTUPI1LKuXQVGIX/ui+rb64EHBLpDwWxY13RsPI10uodAoOKNEVzEtn76X32cY6hWOrUheA3J+DZeaYli2Zb0=
X-Received: by 2002:a17:907:d58b:b0:ac3:4139:9346 with SMTP id a640c23a62f3a-ac3b7a9661dmr197532066b.9.1742372164110; Wed, 19 Mar 2025 01:16:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAJ_4DfQjNRd2k+JBFoR+=Y9D-Nvh4-Kw29nQP=tEYS4BY0B-BQ@mail.gmail.com> <FB1FD652-08EB-41BE-ADC0-C4704349DD5E@strayalpha.com> <43E6C2EC-F99E-4744-98E4-9A9239EAF86F@CableLabs.com> <1116DED7-2068-4566-A947-AC5B57A68FAB@strayalpha.com> <8ACD1AFA-CE02-4886-AC4D-5EA7AA0134E9@CableLabs.com> <AM8PR07MB8137A7C5A9DD4D1F3A38E622C2FC2@AM8PR07MB8137.eurprd07.prod.outlook.com> <C0926071-B3E0-4E8A-AB5E-F0289B614515@CableLabs.com>
In-Reply-To: <C0926071-B3E0-4E8A-AB5E-F0289B614515@CableLabs.com>
From: Chris Box <chris.box.ietf@gmail.com>
Date: Wed, 19 Mar 2025 15:15:50 +0700
X-Gm-Features: AQ5f1JqpxJnFBgZOOLRT5I9AUdhv9uKb-OgSe3oLgEQn5dGIZnKnt86DDcT-Nts
Message-ID: <CACJ6M150-YarOfBxS5GFhcGoj5k+bNefGA4in1rU5POWEpp2jA@mail.gmail.com>
Subject: draft-smith-quic-receive-ts and packet reordering
To: "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e893740630ada1a4"
Message-ID-Hash: 3VKJ65T6XVPI7VPQ6VQUDTXGQWMSE76O
X-Message-ID-Hash: 3VKJ65T6XVPI7VPQ6VQUDTXGQWMSE76O
X-MailFrom: chris.box.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-quic.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Greg White <g.white=40cablelabs.com@dmarc.ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "touch@strayalpha.com" <touch@strayalpha.com>, Ryan Hamilton <rch@google.com>, Martin Thomson <mt@lowentropy.net>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/n2w4DWXa9yWRTFCBulFr0W0zPiE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Owner: <mailto:quic-owner@ietf.org>
List-Post: <mailto:quic@ietf.org>
List-Subscribe: <mailto:quic-join@ietf.org>
List-Unsubscribe: <mailto:quic-leave@ietf.org>

Hi.

In another thread, Greg flagged the draft on robustness to packet
reordering:

On Wed, 12 Mar 2025 at 02:46, Greg White <g.white=
40CableLabs.com@dmarc.ietf.org> wrote:

> The current WIP can be found at:
> https://gwhitecl.github.io/draft-white-intarea-reordering/draft-white-intarea-reordering.html
>

I think this is a great start on describing a widespread performance issue
with common layer 2 networks.

In today's meeting we saw large support (32 for, 0 against) for working on
ACK receive timestamps. Clearly such timestamps would be a useful tool for
senders to be able to handle such networks better, if sent at high
frequency. But the timestamp capability really ought to support reordering.

Why? My overall takeaway from the reordering draft is that many links have
tended to go to great lengths to shuffle packets back into the original
sequence before delivering them to the endpoint. This protects the
throughput of old TCP stacks, but at the cost of tens to hundreds of
milliseconds of jitter. If we're able to successfully move the dial towards
less resequencing, it implies draft-smith-quic-receive-ts
<https://datatracker.ietf.org/doc/draft-smith-quic-receive-ts/> should
support out of order packets well.

Chris