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
- Robustness to packet reordering Ingemar Johansson S
- Re: Robustness to packet reordering Christian Huitema
- RE: Robustness to packet reordering Ingemar Johansson S
- Re: Robustness to packet reordering Christian Huitema
- RE: Robustness to packet reordering Ingemar Johansson S
- RE: Robustness to packet reordering Floris Bruynooghe
- Re: Robustness to packet reordering Christian Huitema
- Re: Robustness to packet reordering Greg White
- Re: [tsvwg] Re: Robustness to packet reordering Joe Touch
- Re: [tsvwg] Re: Robustness to packet reordering Tom Herbert
- Re: Robustness to packet reordering Martin Thomson
- Re: Robustness to packet reordering Christian Huitema
- Re: [tsvwg] Re: Robustness to packet reordering David Schinazi
- Re: [tsvwg] Re: Robustness to packet reordering Neal Cardwell
- Re: [tsvwg] Re: Robustness to packet reordering Martin Thomson
- Re: [tsvwg] Re: Robustness to packet reordering Christian Huitema
- RE: [tsvwg] Re: Robustness to packet reordering Ingemar Johansson S
- RE: [tsvwg] Re: Robustness to packet reordering Koen De Schepper (Nokia)
- Re: [tsvwg] Re: Robustness to packet reordering Neal Cardwell
- Re: [tsvwg] Re: Robustness to packet reordering David Schinazi
- RE: [EXTERNAL] [tsvwg] Re: Robustness to packet r… Overcash, Michael (CCI-Atlanta)
- Re: [tsvwg] Re: Robustness to packet reordering Ryan Hamilton
- Re: [tsvwg] Re: Robustness to packet reordering Joe Touch
- RE: [tsvwg] Re: Robustness to packet reordering Vasilenko Eduard
- Re: [tsvwg] Re: Robustness to packet reordering Greg White
- Re: [tsvwg] Robustness to packet reordering touch@strayalpha.com
- Re: [tsvwg] Robustness to packet reordering Roland Zink
- Re: [tsvwg] Robustness to packet reordering Greg White
- Re: [tsvwg] Robustness to packet reordering touch@strayalpha.com
- Re: [tsvwg] Re: Robustness to packet reordering Sebastian Moeller
- Re: [tsvwg] Robustness to packet reordering touch@strayalpha.com
- RE: [tsvwg] Robustness to packet reordering Ingemar Johansson S
- Re: [tsvwg] Robustness to packet reordering Sebastian Moeller
- Re: [tsvwg] Re: Robustness to packet reordering Michael Eriksson
- Re: [tsvwg] Robustness to packet reordering touch@strayalpha.com
- Re: [tsvwg] Robustness to packet reordering touch@strayalpha.com
- Re: [tsvwg] Re: Robustness to packet reordering Christian Huitema
- Re: [tsvwg] Robustness to packet reordering Sebastian Moeller
- AW: [tsvwg] Re: Robustness to packet reordering Ruediger.Geib
- Re: [tsvwg] Robustness to packet reordering Bill Gage
- Re: [tsvwg] Robustness to packet reordering Greg White
- draft-smith-quic-receive-ts and packet reordering Chris Box
- Re: draft-smith-quic-receive-ts and packet reorde… Ian Swett
- Re: [tsvwg] Robustness to packet reordering Sebastian Moeller