[tsvwg] Re: WGLC review of draft-ietf-tsvwg-nqb-23

Sebastian Moeller <moeller0@gmx.de> Wed, 29 May 2024 05:30 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 56974C14F739 for <tsvwg@ietfa.amsl.com>; Tue, 28 May 2024 22:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level:
X-Spam-Status: No, score=-2.544 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 tso5lXYU7ybG for <tsvwg@ietfa.amsl.com>; Tue, 28 May 2024 22:30:39 -0700 (PDT)
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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2343C14F71C for <tsvwg@ietf.org>; Tue, 28 May 2024 22:30:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1716960636; x=1717565436; i=moeller0@gmx.de; bh=os8KujnnfnC5YhviQisZAYnmlePgroaTBxRLZQNgb7I=; h=X-UI-Sender-Class:Date:From:To: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=DTkWpaYqRIk1svG4yK6ze9X+wRQ4DGZjVVeRdBBbQluIkerjSJkDxzqlVQgJphNH i04qvZbPS+MQPNbJi4O6kQrG+FRLkvgo8NL7a3aFGdcNqxayUTTG+OV63mjUPcJ4A K/NJjgyXWTYK8wZHZGFTCNxUU5M7SkfvNpgNZ7YDwfhqQB4L2DSId0lzdm7+L/LCk PvfgHngbuwgjvcNmWCfzsNA5PBVwUcOKmFn8w4QE+PljoW0V9tjG5z9m2tXVMcO64 wUvRriokgJ1cbN9Cgpq/YBNI6Z72FTwPlX1jPHWbgD6Pvf9E1Z6DdfDCKtDanIDM+ FR/AHEFCIGujwERkAw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [127.0.0.1] ([95.112.93.240]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MBm1U-1sM2iG1UiK-00C9dX; Wed, 29 May 2024 07:30:36 +0200
Date: Wed, 29 May 2024 07:30:33 +0200
From: Sebastian Moeller <moeller0@gmx.de>
To: tsvwg@ietf.org, Martin Duke <martin.h.duke@gmail.com>, tsvwg <tsvwg@ietf.org>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAM4esxSfvesaW6dH0GB9_NKUhzWgXcg9SApUcxE=VM86e3jeYw@mail.gmail.com>
References: <CAM4esxSfvesaW6dH0GB9_NKUhzWgXcg9SApUcxE=VM86e3jeYw@mail.gmail.com>
Message-ID: <DD7C6D56-4306-46E3-85F7-4E92BAB57B17@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:0x1fwWYGhJA0XEMfZGqHqEgZPYMXy9y1drVA3R5EGrUhWp0cdVS LTqn/ldpJm4DrqC9pMY7u4KaOwYzXBRcoYTA0igb4WlHw/zaITzRS36E+IIzNGUBPZjQDu5 ieeW0pvKguELbxUqLsSHqLlAN2dLUYCOSkow9fMNB96qmTTT/NjFZ/HrGKQN/d6Z/iM1uzl mJbCCJA02GxDUpVbYlu8g==
UI-OutboundReport: notjunk:1;M01:P0:3A8jCK9Hzv4=;fXq06OD0JHjlukwiI4bW0NfXwVy 38Ejq2wrPB6kS8dKxI92CQPlany4BikDh8Iol08wp2nn6uM+XftlGx5XMWoq/XXFTaVvPYU0a ka8NF2l76h+3ixuEOGqNeXYLqiQRfTYvC3qdFLd+HZcEGqr+YbAT0ismMxD5DBZJnDPNqGTtq W5k7MyWtP5dz4nTVwZLJk9949vleKHt2MBQ2nyh3NtXo4PTwUhTLMdslgWEhmMy7/Bx+MT1XW PNDBj8qCJbseXXBCgeZ9OWb5upw5NFnHDAiAGNK7I+9xjHccXdVps7+GQaMP+tbn+Qrlfl7Fb DDwvJpKub+0FjSdfWlOGgeO5VOQ4la5xhyto88KRhpMWdDewIOM/qA0/4AyDNfHQvWUvWvnMs 4NbYOcJuUnuUfAtdeyyb/AMZqnrZseT0jwMThmVt9n25o325ozdFjXC46mJD0Ay1gtm6bt9Yy Dixo5+NvyCm+Bkokr1FDFO+0RN7kIMlWTie665/LDdLUPd8v9UAyEI9yWdGElUlUqEu0yTUgp abVRraNYMXJH4wuBEU01V5PYesS29vukUaHlxg4PjoBwvA9Xm3RfcBVXd2/H2YIOgSgCCj8AR QcOXwvmEimgCF0JRsLmTVwislbRxyTWNeKhKnzBQ6I8nOQDUDEEqOL/3t84gmQdNtRZcPIiUZ Nf/7/ytfTxA2frIKKK2krt6dzfGDGei/55cAnI7ZIKgTX6glt1NHJk6dPLpCgvbquUUoopTM4 cElsFJqwomCEKeN6A0B9mHxScgDbEPNXnkefoqEDgbhuV1DWXevIkFHvr0nl3qqVH0Y4gDjKX 2gIYDDHfiR4y6r/kURJqrslCZ3EISvEtV5J/iyBtB9vdg=
Message-ID-Hash: 5Q3ICNFTJ5GPTXG26453Q2WXX4XHODS3
X-Message-ID-Hash: 5Q3ICNFTJ5GPTXG26453Q2WXX4XHODS3
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: WGLC review of draft-ietf-tsvwg-nqb-23
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/J8tGyumX0pii-mFF-j1nDkica-Y>
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 Martin,

On 29 May 2024 01:23:40 CEST, Martin Duke <martin.h.duke@gmail.com> wrote:
>- This document appears to rely heavily on magic numbers derived from
>current link characteristics, and it's not clear how those can evolve over
>time. There's some loose language about traffic policing and appropriate
>responses to that. DSCP is a somewhat more loosely defined area than
>others, but I was hoping for a little more precision in a standard.
>
>- I wonder if keeping a token bucket is really needed, or just keeping a
>very small queue and looking at what flows are filling up that queue is
>sufficient to identify bad actors.
>
>Nits:
>
>(1) "A node supporting the NQB PHB makes no guarantees on latency"
>
>Doesn't the size of the queue provide an upper bound on latency?

[SM] Well, for the linux dualq the guarantee would be approximate maximal queuing delay or drop, and with queue protection the approximate max delay is the QB queues max size, but there is also a potential helping of reordering...

>
>(4.1) Is the number of bytes sent counted at the IP layer (i.e it counts
>the IP header and all layers above it?)

[SM] How would an endpoint actually know about the effective per packet overhead over the bottleneck link? I have tried to crack that nut for years and still only can reliably solve it for special cases like ATM/AAL5... so I would be delighted to learn a more generic method....

Regards
        Sebastian

>
>Martin

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