IETF Logo Mail Archive

[tsvwg] Re: Robustness to packet reordering

Sebastian Moeller <moeller0@gmx.de> Wed, 12 February 2025 07:05 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB6CC19ECBE; Tue, 11 Feb 2025 23:05:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqbP3NQsm52J; Tue, 11 Feb 2025 23:05:33 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32911C14F6FD; Tue, 11 Feb 2025 23:05:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1739343928; x=1739948728; i=moeller0@gmx.de; bh=cqosI+nwbA64zgM0yDR/BnZ9IhOcw0CergLBhkev6Oo=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=t0Qezw0jvq4fa9YH0xb3h0S1EUTexXM7qFvFBZIyxF29/73/lAe747QJQ5GBrxFj o1MGm4blXNHrIBgjPFW3DZ3OCTNwGrqmo+dGTcqvNQfG/vurWKxvrx2H5SI2uIrjL GwOPrrQ23YuXqy3AbxDU8CxlfYInEdeRAVDk1W7BMO9m18azYHbYCJasjJhyJxLlI V5jChn18S3OtGavS+YjG/JcFwvNADTdZKvV73QQrwdecO/GhLE/kbRzSBQ+f1KfR9 zI7TypsBO+TAEQ1wv5D9Pzx2HW2skzAxr71EkvQj3Xv1d/T4ori2TY6KiIdMtRAHb fVlrKQoTW0kOH40eCw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [127.0.0.1] ([80.187.112.247]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mn2aN-1t015L1Nkl-00ZfO2; Wed, 12 Feb 2025 08:05:28 +0100
Date: Wed, 12 Feb 2025 08:05:24 +0100
From: Sebastian Moeller <moeller0@gmx.de>
To: tsvwg@ietf.org, Joe Touch <touch@strayalpha.com>, Ryan Hamilton <rch=40google.com@dmarc.ietf.org>
User-Agent: K-9 Mail for Android
In-Reply-To: <FB1FD652-08EB-41BE-ADC0-C4704349DD5E@strayalpha.com>
References: <CAJ_4DfQjNRd2k+JBFoR+=Y9D-Nvh4-Kw29nQP=tEYS4BY0B-BQ@mail.gmail.com> <FB1FD652-08EB-41BE-ADC0-C4704349DD5E@strayalpha.com>
Message-ID: <56B1E0D7-EE02-4D6F-9BC3-90FEEB4EF98D@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:UDun6nmYlMfF9Br+YCX16hsrbHa+T6Hg4gbtmY3VJnWhBHBoStX Kb4hcK+OOqZcfWZcMoi7KGkJMlfzIsCGx+eRJCp38uKDsG4IAh1VMD4hvBMxOO60twSPCZA aRSXYBEGOhVByhQVTBvhijF6vjInMAdgl2n5PvFeXnqFlCrsg3Q6pop1OQBYzST30rDCyDg TzGbFmucxVnIgR6nWwtRg==
UI-OutboundReport: notjunk:1;M01:P0:k1twJvjMGW4=;baGrWfqxeumKmfap9+xWtqJUjGm zwC3iwc7rDQDx4RUV/6ANf9h+9iN/7qPYkgoKQ8tqt/lnkcDmH7tb578QymczyzVhV2pJkHD6 or8stoTUWR/qYRYygDv0mhVk1BGbIgBY7p0BA4+OXMmNdPu+B1S2fXogw9t7XTwQmdtisvCYX UW0SoyVgAvHzI1A4pJ4+TMttHv3Pe2ml5ezUSET5e9ePUXjMNoPcUZlxsiIYy2ojr1FAB5LV2 FttC29TjwC8ZLi/uqDAkEpSadFkiEcT028t82aewRd6kfDysVkjbl3HAy4oX2kr3jAuGmLcOS fLdKQewpyIxAjjZSGzb/pSX5yo/4zDcKGsoWXGmV7pyHVLJGgQMfUJit4KQAEtrw2eRrUS8UU IwuCckQJ1Nxv6xhwPefIDivGPj/m43fi/VHgk1fTP9YdgIJALigQL0/N3/1HfnOWhQScNLcdm imLb/wyzdvbS802go/+yyGjrazyIOD6NzoNZaAYt3465IYqyV6PQQXGpkOx/xcSTfgFHhnQsq u19qvjo7QKArwhJ3aGUwZDPUseVwt77Ufgyi+FQxKXgiBjoTcZ3aFSW8I7qHCZM18Et2jDlx6 H0BWfxjj0kkIvFFM1DTPihicaScZGx93A6ZNRWzYfr27+ae55JluSmP0zKBalbhquVP4Tezyb 2+s73JdJFyJnIcAVkUAdA7XIt4l+Guo4LSdLt8AMHos5xSdp3CT3fL0TPqEPVeGE2dL3U7mYL fUZ9DJl7a6rVTUi9cSVeF5kJXxIZPC9msfJjAPhD75mIYz1Adq3iNOzQ2a8cA1xwforS5BPBr ArcGz/3TWUhpmt0SOPf+XjvTRiEmpm9Tn+H4IQzE68CKrtFnaGPzADdLzOJHyvXLt2bRKE3zZ 1aRnaumFVG5QyA/JchcK4jkwSbdC9nGZ4QFkdoFdx+Pk84TFQS5XHckJGfoTq1+/7KInSIjXP Oux72zAl4GZGOKv3n+pByZ9m1S4fQrFlLLyZrzjXPpUqqe1tMt4tC1qZMJtk56vsV9PAgecIH 9EFYrkRw9MFz8fLxhIOrqSpYuc2EQjRKUrKAr8CB5NcOQXBAqC55T54k3xqCU5CbJB6Nw2Ipu UGERi4hPyNB2u0Y9Sdl7L/qGbpTmM1RbUb6AUF04O4W1u6XpgcnDA249cXXPOdcUJRJb8hLqt lTiBNBw09hK7FnyfAAalut3pXv7vetlrWH2G4TFL/3YC+h1cGBTH3jYbBKSYG71ZWQ5kVbqr/ vIwPTsVC3w7lgPgWk6/eMqK84CkYhaZLyd/htBGUfx9l0Hrlyu7TtOvmY7Rm/2BCilIUvy/yH VIU5TULTwhYDWG/XxVJGWNmx5S4GMibGSnpVFypYER0lDTTzHqAek7+5COmZ8V3NVDnzwfRla rNUoiKe5nTHKjEjoNyj3sFIX+UZZftxVzD6dOKek4zN4m8IiSlAS4SDd/X
Message-ID-Hash: BIBKMRGZNHSDYWNGK3RQPEHRN2INWEG4
X-Message-ID-Hash: BIBKMRGZNHSDYWNGK3RQPEHRN2INWEG4
X-MailFrom: moeller0@gmx.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Martin Thomson <mt@lowentropy.net>, Greg White <g.white=40CableLabs.com@dmarc.ietf.org>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, quic@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [tsvwg] Re: Robustness to packet reordering
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/7sLNUKSgzNeiccxow51Fplpi_e0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

Hi Joe,

On 7 February 2025 23:17:38 CET, Joe Touch <touch@strayalpha.com> wrote:
>
>> On Feb 7, 2025, at 2:12 PM, Ryan Hamilton <rch=40google.com@dmarc.ietf.org> wrote:
>> 
>….
>> Let's not hobble the performance of modern protocols in order to *potentially* provide minimal improvements to the performance of obsolete implementations.
>
>Agreed. As I noted, RFC3819 still has imo the best advice:
>
>   This suggests that subnetwork implementers should try to avoid packet
>   reordering whenever possible, but not if doing so compromises
>   efficiency, impairs reliability, or increases average packet delay.

[SM] This really is just stating that reordering and undoing reordering have both positive and negative effects. IMHO it completely fails to give actionable advice how to assess and weigh these effects objectively to conclude whether/how much reordering in a given circumstance is acceptable or not.
In a BCP I would have wished for at least an example how this trade off is assesses in practice... (or multiple examples if the exact circumstances matter a lot).

In a later post you assess that 13ms reordering window acceptable and in accordance with the above recommendations, so let me ask, what is the threshold for acceptable and non-acceptable (max) reordering-induced delays? 

Without objective measures for the positive and negative effects and how to aggregate both, I am not sure RFC3819 really is all that useful in regards to reordering.


>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

v2.29.0 | Report a Bug | By Email | System Status