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

Greg White <g.white@CableLabs.com> Fri, 31 May 2024 22:50 UTC

Return-Path: <g.white@CableLabs.com>
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 30724C15107E for <tsvwg@ietfa.amsl.com>; Fri, 31 May 2024 15:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=cablelabs.com
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 BdXVNMwzBO5d for <tsvwg@ietfa.amsl.com>; Fri, 31 May 2024 15:50:47 -0700 (PDT)
Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02on2125.outbound.protection.outlook.com [40.107.95.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A90C151076 for <tsvwg@ietf.org>; Fri, 31 May 2024 15:50:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AhEPb2u+PgXbPpHmEAluwh11cibRWkHwXSCgycdFaCfc4zIIHfIcwI/Bja2NlMzOSBtfHSzRizvlPjbefY5Wb3Ip4exJpB6QVL982Wbb/cdQVrwoLelUTG8Vdxx5Iwl4t0qDWa51SoDKSz9O6LFBuIBEjZDeSV0xO/8DLqnC2fK3pVXPSlO3Hf+WyDVugI/pet1iuJVEMqAOTxnBlpzI6GnrB2HO2iVYfOb9TcevCZsN/KMeySjmwtzh+F/tCpykXabGco/QzD52l/bcgl1X1ACurhXxUHIoITR1fc2fIi/QwPeaDMq2X8EO6d+Tg5wl4UOLdzCcwnXZZWCnn5siSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aLNdbDxqJ5zIDsuhOLPJL8UDhLP2bISEJUofugAp5q4=; b=H6mjKP6D4a3cT58kuIiRSD/YI5nvRpN735Ga6i6xxeq2/EDeah8G4i32N0Fr6Q7eQel92/9Sves9bZ59XR6u6ZV/AbKY/G7ZntmsMtOvfHm+ABCIBRrfdqrpnHU5LzGkTGIHsE4SKX7La0cHI+zLwg8jWJ/GpPgY6HbJ50EGEXpP2bZxL684gb/ROP1ablUk1MtBDuNyZhBmMS83g5z3QQryGYMqscm5LIg2BwYUtbvvZmG8e2KIj31EohpOJaFm0Us40p/OSriu4j6P/uXAqkGfH9Wtpoa1EQE+2rOjrkIHJDzbCamYQLfhafQ2NwGNPi6j1+pw6Q7O4OsxTTvByQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aLNdbDxqJ5zIDsuhOLPJL8UDhLP2bISEJUofugAp5q4=; b=ShfAKzBnbfW02t+MdQcoU2y6uqtogiHVJtWcD1UbhAzJQY4bEmnMdfjro/PmFBhh1CbrQ3f9/DNsGNleQSwLKLFqKUzwx1sQRRC6NgEF+vLHDpr1pMUJjhYFZJEF34zPJXlv5sGypJaYH/QVvR2zrRHizngJK/pkaBcugk+8tQVA5qzc1sPrOXsWurXa+lCAu4vykWpETOQc4DJ/+YQd9aSmWX0Oie0FBGfmQpufUNX719gqfGbbKQ9lwhs9RGYouw+EVvNGyEUhAI9ESUkKI8Ldzm+9CE2WcF1WQ9xreo27lyWr5m96rgp6AiLrgWH2ilHDCmr/vA1mZA/jYtfWXw==
Received: from MWHPR0601MB3657.namprd06.prod.outlook.com (2603:10b6:301:7c::23) by SA6PR06MB10103.namprd06.prod.outlook.com (2603:10b6:806:422::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7611.30; Fri, 31 May 2024 22:50:44 +0000
Received: from MWHPR0601MB3657.namprd06.prod.outlook.com ([fe80::5c72:2ea6:2bca:4b44]) by MWHPR0601MB3657.namprd06.prod.outlook.com ([fe80::5c72:2ea6:2bca:4b44%5]) with mapi id 15.20.7633.021; Fri, 31 May 2024 22:50:43 +0000
From: Greg White <g.white@CableLabs.com>
To: Martin Duke <martin.h.duke@gmail.com>, tsvwg <tsvwg@ietf.org>
Thread-Topic: [tsvwg] WGLC review of draft-ietf-tsvwg-nqb-23
Thread-Index: AQHasVYo+5ogf3NdlEKjnr3lKdM0yLGxkq2A
Date: Fri, 31 May 2024 22:50:43 +0000
Message-ID: <01BE88AE-719D-4631-92A5-878A8BC151A7@CableLabs.com>
References: <CAM4esxSfvesaW6dH0GB9_NKUhzWgXcg9SApUcxE=VM86e3jeYw@mail.gmail.com>
In-Reply-To: <CAM4esxSfvesaW6dH0GB9_NKUhzWgXcg9SApUcxE=VM86e3jeYw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.84.24042118
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=CableLabs.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MWHPR0601MB3657:EE_|SA6PR06MB10103:EE_
x-ms-office365-filtering-correlation-id: 36468d7c-0bc9-4a0a-454a-08dc81c41a95
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230031|1800799015|376005|366007|38070700009;
x-microsoft-antispam-message-info: fpMuFJ7rNrdOsYjztmHCgXSMcuGg94vR7I7Xu+cjKJiEYOPI8Zp9H6Va0F9Doj6sc5xPua5rodZZXT8X4KQybYyFNn+T8RWKMFQsrm4pvUa/ODHF8qcQPNjpJYbRFmqj+ZzdRaFuPzEOpGy1pan/3TWQAEM8xFonNnJWbjbF7//EQYhicxgQyzGKv8Kn6ggG9Wt3JPTgSRrm77TMk/GIt0wK/eL917dNvD5BjG97711PImKUn69G18Oee/GrcSHdM06FlNNbpooYbQ25wnilAFtqPHb1+XMJqXkfqcbzTiSmnPE0zzj04OLezI6cKFh02FHeXX5kF6o14Q8Wy+Jd/S5GQVc2vN5nPS2kL6esZN1pJbK4m79tPTYA0xO/MqDwT0b9V2YERBhQQtc9phUkbDuMlmqbW03N+AA91nYMWpvTi5Np9jJ9659xgaj+nYO9qo9zAx4gzZ6NIW9rCje/6WABHC5AaywvVVh2YNUd7edELvf/Fy0nsdu9dMCUsnrgvnJc8s9enXAtuwyBojcdO0Bz2fN7bZmd/8VP7jaRIYgpjdO5uRT7mDaf+DZdZZGx/LwRPzPZhL94yHsto3+6r71J8EKL5+qBHtzYqU2ye5muyIid26iOtO7iKY3SX8TkjPqfoyeuwDs0G3mjuxgHGXWd07s8xjIvXNJVqcjXJjRgQbgF0vaVgof4rQT64AGkhrlrLNlJE3M7o0nWDcAvpPYSKKA6YuSeq4qzqod/+S/VlVhGfX2MtMpic0jWi7/g/C27QatwACuEswqubiS1RtHyz9zoXnaNbDkaYl+6q9tEC4nwVoV1c/4aHSOy7eRNxuH4MeDArYE8jJijz2hfqW3+SmpzkIgcqc9APiRZkITMNNv+zld+UVYhD+L0Ijq1aNgeZ25CH894MoATl9d2l28jG56xtZZjxvjLg1q411X2xSumMzUkXS+E78nbfFKbUqnwC8B4xaeHaYksyPJsxqRDBP4SfXoypsqKrijCoYwEnx/s2zAxc3AquIQByw6CIruGA3ybxpM6tYvmM9TyQqZHlU/1ykXWVJekJxlJRdscq74Y9cyhqdbVz5u/LbwDCPS5sDkjza2N7Tj7BZz7UvI931ffmiWGKLZrfhhfcJ3JrM9OyIwfoRJMLm8tUyH3KMTPyoMivzqZlpBrEkJgHipVW61LcsKyNLwnR6FwGOtzgejuwycV44dAk97RHZAtckxs9gbXhehsiUsFK8tlpfheqKhSXvuxTcdRyskJY22hfusbjGuGLQQJO+QemReDw2QmJBOxYcZ21AqHixsiww==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MWHPR0601MB3657.namprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(366007)(38070700009);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: hxm8NMiR5QdYnQLx+blhylxSb6WfCARc+uy3oZJlEh3NpJTj16fkPvxEHeZWfFuPK1aP07Gmcj/mNwVRyPjMdVOA68JLXNoq/G46mfGZ3IdoAiJ3zSaPj/Qb8Lr3RYDsA0mhew7UZmX0IzZBvsEUmxCNoGiF/9dJuko4uOFdMmVydO8yzwgq1BHEEOxWNLviXjY7YZrA8FtfzGfcXCi9UT5czOYIJDYyHQLRet5fDVDYZ38nm6VN/bPz+tgwkx68n3nr2ME3Q7pzK9QYIIW7MktCRT2GN9y/rx8dxDG0Sr3m8NPAaaUD/KWmf0eS0ALIkCbhA0xVsoC560AF+7cPV1hw0LvMsYeMI64o2CwKVPG2SY07eGfbOhMI2d5ft/ASb7uGAerLdRvj8ZaXWtlDbtZv+z8aETd0eUzmPlpOU0RnTgqetOwX1Nk8/vk6uhPp761buF6HSOzIo/CuEiE7uZdnpBuFg4wlkoPQqZN2UePbye+o3M+UmSYzKHFFhd1nVs67FzMKmifT6O09fUqSSOTb5iJdpkyrf8PYAtiWUyJ+FzFK8/99Eq/ypQmVlFwsYsLOYZezGcWQOK635zukrgk8KBf7mGDbikAy8gZwWYNTHhq2kE//XKTnsKdMlKFzUeejquPiw1YFZKzPYkPHoV1482TodWtmXW+MeSUHLbBBA1E1FESFbDIrM70MdSyY9hDMyvTKQ487Ci3wwlFhX6Lmzwu292xPOJQhUttpU10OHkRTNpxWMsgaUszekM3QF7bKcfLMbUWqrsZs78v5/tDxFre4gOaNCLyiaY5UdZMy37E/1EYRZcsUIx5NlIjD5XZGwhpUd28+1jaZiEQWAbsusi9N62yPoulr61/3XJFhxJ9x3kaWq6lJtm+5dMShkArFF1PWDz5meaHolNyzkoQo9mzR8m2uTBjhC0UuXXXep6wqbY7qGlW9q5ItuykjDCVAYCB2AlZtryw4aE+cP8ywBX915DT+WGu3v8sE+MSSyHMdq+mQ/uoT/rU7WDa4qHe956GcT9Z5gbdIZUQRjmoxtWXIiExkJa3zM/VQD/1Rzo2tt9d69H3ZaOySTtkZSv9D7ffg7DVPP91PO/4msM238qT45tJxbHV8+H0RL/3d6MCJoTGRIJ01NX1MLi6XUc5brkCfH2V10RGADoP1pTyDQ1Se02WfOX3aE8CN2ggM2cuvTumQ+B5btxkUzKKAYc8wThujVTBDD+SXqEaxxd0j8Wzjkj1uXJtyB900E7wjHyff3sMAmI4huyrDRlvExNh17sfJNcblUXdhejBu6Xd2m8b6mAINAY9ZRwBoimO/U8x7cIr58BDbkGLncVaaONQz+18hXOhwpJX37XtB9dUGWUhuIZCFco5wzxd2uFlbf/i/r5tf9S7iH+gOvGpKDV1wp0O4UEI57bw63nR8UbImh8MgO2yIM4y6wq5eW/zXg/UsFdRP5/f3spoqlRoXdIq8hE96FPLXZrGlsn4lPNgCmNu+PzmHqoY5DKNCZdADz23/e+IrZswAtTgwHviEfJHLdLJ/qpmVm/GxHLpFFF5x/1ow85qUZfBicMH5B9bzfdBvG8XkjNtn2bkjdNcXJqDqvXlgOfkotgb/hNo7+/zfVPgCx833JtiLRaOdumg=
Content-Type: multipart/alternative; boundary="_000_01BE88AE719D463192A5878A8BC151A7CableLabscom_"
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR0601MB3657.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 36468d7c-0bc9-4a0a-454a-08dc81c41a95
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2024 22:50:43.9294 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bUpmAQonRC9SH1SVEeyEw+x6DOs4L7F11YaXLS8Vw+hSNpdS4tgo8VA55x9TzOgeaeM5mnxDCk0apfwj0uJeUg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR06MB10103
Message-ID-Hash: 5P3GCESKWFF6AJKDXRPS7WYL4KCNLAQA
X-Message-ID-Hash: 5P3GCESKWFF6AJKDXRPS7WYL4KCNLAQA
X-MailFrom: g.white@CableLabs.com
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/OY4eH37IWb6LB17kWyErNZwEawE>
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,

Thanks for your review and comments.

To your point about relying heavily on “magic” numbers with unclear future evolution.  I’ve tried to pull out all of the potential instances here:

https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-4.1
~1% of “typical” network path capacity - This is explicitly defined as being relative to “typical” network capacity in order that it can evolve over time. I believe that we reached consensus on the 1% number.

“R*T + 1500 bytes” – based on the typical Internet MTU.

https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-4.4.1
“the policer/shaper rate SHOULD be set to either 5% of the interconnection data rate, or 5% of the typical rate for such interconnections, whichever is greater. …. The recommendation to limit NQB traffic to 5% is based on an assumption that internal links in the downstream domain could have data rates as low as one tenth of the interconnect rate, in which case if the entire aggregate of NQB traffic traversed a single instance of such a link, the aggregate would consume no more than 50% of that link's capacity. This SHOULD be adjusted based on any knowledge of the local network environment that is available.” – automatically scales based on interconnection data rates, and guidance is given on further adjustment for local network conditions.

“A traffic policing function SHOULD allow approximately 100 ms of burst tolerance (e.g. a token bucket depth equal to 100 ms multiplied by the policer rate). A traffic shaping function SHOULD allow approximately 10 ms of burst tolerance, and no more than 50 ms of buffering.” – provided in time units as opposed to byte units so that they automatically scale with link rates.

https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.1
“It is RECOMMENDED to configure an NQB buffer size less than or equal to 10 ms at the shared NQB/Default egress rate.”  - as above, written in time units so as to automatically scale with link rates.

https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.3
“However, it would not seem necessary to limit bursts lower than roughly 10% of the minimum base RTT expected in the typical deployment scenario” – expressed relative to contemporaneous conditions


So, for the primary link characteristic that is expected to evolve over time (data rate), I think we’re good.  It is clear how the parameters track network evolution.  The “1500 bytes” probably could be replaced with “MTU”.  The others seem to be the parameters provided in time units. Are those the ones that you are concerned about?

Other responses below [GW].



From: Martin Duke <martin.h.duke@gmail.com>
Date: Tuesday, May 28, 2024 at 5:24 PM
To: tsvwg <tsvwg@ietf.org>
Subject: [tsvwg] WGLC review of draft-ietf-tsvwg-nqb-23

- 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.

[GW] Yes, other standard PHB specs leave quite a bit of flexibility as well.  Is there something specific that you’d like to see changed?

- 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.

[GW] I’m not sure I follow this comment. The only direct discussion of a token bucket is in the section on handling situations where a downstream domain might provide DSCP 45 with high priority.  In that context, we do suggest traffic protection (i.e. looking at what flows are filling up the queue), but since the “queue” at the egress into the downstream domain may not be the bottleneck, we also discuss rate shaping/policing the aggregate of NQB traffic (in which case a token bucket seems reasonable).  Identifying bad actors is a role for a traffic protection algorithm, for which we don’t directly discuss keeping a token bucket. Perhaps you are inferring a token bucket from the discussion about potentially using a per-flow rate policer[1], and then later discussing hysteresis[2][3]?  Even so, the draft suggests that looking at which flows are filling up the queue is a better approach.

[1] https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.2-6
[2] https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.2-7
[3] https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.2-8

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?

[GW] I suppose that it does in some cases.  A simple fix would be to delete the first phrase of that sentence (up to the comma). Is that what you’d like to see?

(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?)

[GW] Yes, that was the intent.  Would changing it to “number of IP bytes sent” work for you?

Martin