Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate

Ruediger.Geib@telekom.de Fri, 13 October 2023 07:00 UTC

Return-Path: <Ruediger.Geib@telekom.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 1E184C14CE39 for <tsvwg@ietfa.amsl.com>; Fri, 13 Oct 2023 00:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.803
X-Spam-Level:
X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=telekom.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 iM-tGECEO2Ld for <tsvwg@ietfa.amsl.com>; Fri, 13 Oct 2023 00:00:09 -0700 (PDT)
Received: from mailout11.telekom.de (mailout11.telekom.de [194.25.225.207]) (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 3D539C14CE5F for <tsvwg@ietf.org>; Thu, 12 Oct 2023 23:59:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1697180401; x=1728716401; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wlwQB4nZwifddcIuO0sNs47iCqi6drwGJs0bFjc+rIw=; b=CfoJPjEBGf+3JFZGzw+Upn+NycIF/w+JFE0iZb9IVXFctfgoq4IDRD9a pVayNrOKhfdc/2pHUkLXlOB2i4NcxgOpXm6ix+XIp99I1skHAxhitSPru 1MWuKdPG/y9wzKuYdKmTqL4s1LDhCoQXggPESzIABrxAV0sG2JdxSXCL8 hnEIOkF1VSBC5eLPNJcoEI0eQTF5PbOjkDR73fzuhSVF/PwCigtnvPQ5j LmXR3XDzZd977bJqOGoi3goFp9p93WWC2z04VHBNxmL+uSq4JA/Ih/WYo k0NIpi0oY2nQ3hYg8nOvD7s9Kg72gCso3yxEESYgl7AIbQSni7p2KDjnI w==;
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT11.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 13 Oct 2023 08:59:50 +0200
IronPort-SDR: 6528eae6_Oezqd5LvtN4417PTb4NWqGVzJ8KM+e0l4mTe0ito+W6S/jR OT2EMY6mSMwdWDwLuJ6YX70Kztbp1c5537Ecwdw==
X-IronPort-AV: E=Sophos;i="6.03,221,1694728800"; d="scan'208";a="776970864"
X-MGA-submission: MDEKrna1OJD8Bs9/dRbm0/7wATbloeuJoW9v1UZ7p9vI/+4ajPFNsQ+dgXlbziByStrCg4e+GmGO+ZcHCNnyZPDFnuj48VuhDec9xdxf4EkEbbMFrOcgInxftFdqRkkq7Bla7Ow9uQeGBZk/OvzamJvKCUfD/RdGmt+1jehkKJ8xcg==
Received: from he101419.emea1.cds.t-internal.com ([10.169.118.196]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 13 Oct 2023 08:59:50 +0200
Received: from HE126305.emea1.cds.t-internal.com (10.169.118.206) by HE101419.emea1.cds.t-internal.com (10.169.118.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.37; Fri, 13 Oct 2023 08:59:49 +0200
Received: from HE126306.emea1.cds.t-internal.com (10.169.118.207) by HE126305.emea1.cds.t-internal.com (10.169.118.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.37; Fri, 13 Oct 2023 08:59:49 +0200
Received: from HE102771.emea1.cds.t-internal.com (10.171.40.43) by HE126306.emea1.cds.t-internal.com (10.169.118.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.37 via Frontend Transport; Fri, 13 Oct 2023 08:59:49 +0200
Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.169) by O365mail08.telekom.de (172.30.0.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.37; Fri, 13 Oct 2023 08:59:49 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a+LtdqEKvpOqB0tQkFq5P/9fvAKqXX/XOHvgF8UoUQNBHBNYsvx3jjOtu3dVZKX7SkMZb4yacQto3OrErNi+HapPLuuqwZIFNBLNJbeuwW1NpGhaXV0p9D8QxDlAMcroWymgb3d7QL9lJa/UbNUgLHjnHc6N5haFJb2XFOJMWcXY22T0MAtJdGkLiEZDRX7+jEi2UFIDOGHuwfg3eQ0h/ClvDk4DMr5QxHFUGkHGHNjFD47rx6FHiGAqGVeQTdfsn8+Y2xSmHgZ7kfyHMYLoE6bHMQKGNLz5cMI1Nar07mhbereXnQPt56/xxKWaYY6NVPSI4QB6F/UAFyPRnTMl7w==
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=wlwQB4nZwifddcIuO0sNs47iCqi6drwGJs0bFjc+rIw=; b=JA1WyMYNSUQblCdRh+VnGiPf33u7Yj9uoppjqdO3fmy5CI+bfHwlCOQEIiRLUV0vcfN9WYZT4xZOKz5tGEjVGwr1cgMETWIt5zmhJgbrqF1OOG3HS5KUAcrSsdAYmah3tlsqaSdo/K1U1FK7rQ8X5IRzETRqBe2WTKACzOI3ACDogdbIXq7U0jG/o7gqsO2Ai7k5aK2Sj8UY6Fpp9lmUSitoWVnHS2fv+RocYb+ZtlT4WKSyFkBfNGi7m7nGE9QAYACdA7WzlJS2t7kEChhaoQKpJFXCvG8XFgGNSPFSpwR9uUS/CvCoGGVDWDvEOPWkA9ENVbqLvNqWP3ZPlZO6mg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:8b::11) by BE1P281MB2305.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:30::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6863.46; Fri, 13 Oct 2023 06:59:47 +0000
Received: from FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM ([fe80::311a:51bf:7934:882b]) by FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM ([fe80::311a:51bf:7934:882b%4]) with mapi id 15.20.6863.043; Fri, 13 Oct 2023 06:59:47 +0000
From: Ruediger.Geib@telekom.de
To: g.white@CableLabs.com
CC: tsvwg@ietf.org
Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate
Thread-Index: AQHZ25vZaUsz4jm44EKXEh6QykJxzLBBZN7AgAH2JYCAAV1GMP//+JoAgAFFPECAAFO2AIABP1CA
Date: Fri, 13 Oct 2023 06:59:47 +0000
Message-ID: <FR2P281MB1527F1D589CF955083C281059CD2A@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM>
References: <5B112847-5653-4946-B25F-393F903795C1@cablelabs.com> <FR2P281MB1527DFEB233461B2EAD94D049CCEA@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM> <468CFA50-F9F6-45F4-98F8-F610CC0AE74F@CableLabs.com> <FR2P281MB15275E16BC2DD085E7C42B729CCCA@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM> <1125B29B-0132-4E85-9470-F4419927C7ED@CableLabs.com> <FR2P281MB152756E5ACDE96B1A91858CA9CD3A@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM> <806C5BA9-A506-4D2E-AB8C-33E0DCF49478@CableLabs.com>
In-Reply-To: <806C5BA9-A506-4D2E-AB8C-33E0DCF49478@CableLabs.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_698f4495-497e-4165-8f3e-980c2f21975e_Enabled=true; MSIP_Label_698f4495-497e-4165-8f3e-980c2f21975e_SetDate=2023-10-10T10:52:50Z; MSIP_Label_698f4495-497e-4165-8f3e-980c2f21975e_Enabled=true; MSIP_Label_698f4495-497e-4165-8f3e-980c2f21975e_Name=Public; MSIP_Label_698f4495-497e-4165-8f3e-980c2f21975e_ActionId=d2b5fdcb-b4cd-4677-89cf-619cd22d019a; MSIP_Label_698f4495-497e-4165-8f3e-980c2f21975e_SiteId=ce4fbcd1-1d81-4af0-ad0b-2998c441e160; MSIP_Label_698f4495-497e-4165-8f3e-980c2f21975e_ContentBits=0; MSIP_Label_698f4495-497e-4165-8f3e-980c2f21975e_Method=Standard;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=telekom.de;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: FR2P281MB1527:EE_|BE1P281MB2305:EE_
x-ms-office365-filtering-correlation-id: 172a4115-5318-4c79-13d4-08dbcbb9fccf
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dEqB3QZpT3Ic+YXAsfwssQHVRv+sYHP331m25CxnWvz+8mq8iCjsx6YNKgK48AoYOnyWZSJSTFjTBn/zXAid1b8o2cAMUTbgsxEC+zRDdsyk48BMJdoqa1jWAND28vx7vytqqfeCoJHEmnsyEhue9GZFrsibBtkHVSTI3PoGkIu6RHr6bPVd4YdbpCINaJEQqfQ7gipD1uqDN/bIkOe/wBHXgQo/DJGDRhsA1FrWByUURbAEHBhuwrEwWF9F0vkUJW9LLl8v/vzQYXuN/dS9cm3o4opZzKZeTb8JH7XDfWPiNf3P55i8PCZHENYU/IkbnlhNv9WQ152z1nmXeRQ11JVUEZx7CuwvGQhLzJHZBkHgVotiyNsOeTz7vrzSHC6j8DDm781IK40Y3poRPLQR2kyvvEFC5ffDSR614BH4+4rBa7UDDGhg9rUDKswu8ImkynGv/4ZDx1wdAvWGFPl9qMfg1CyFiy/KerQcGrayArZqUQrKtxBw+HbVGTgu3DQlGjx2EzI+8HX5RRvTxuYr4H8Me25klCqmR1++wLqsGV3ccUkPlYxpnvCBzLw7hnWGO02aad6XcQPVfdvn/zV+yk2hrTQnbL09FEIYv1HnH7cpwDhIhKJMVS5A/7lZq7O0APFgfE3nWUhwmvHa6Fv6W4j7+svqh+DZIZPNJcNyO1lkoPP2RIYtUzlXcqT9Bknd
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(376002)(366004)(346002)(39860400002)(396003)(136003)(230922051799003)(64100799003)(451199024)(1800799009)(1590799021)(186009)(66946007)(55016003)(76116006)(66476007)(316002)(66446008)(66556008)(64756008)(30864003)(6916009)(2906002)(86362001)(5660300002)(52536014)(8676002)(41300700001)(4326008)(8936002)(85182001)(85202003)(1580799018)(33656002)(478600001)(66574015)(122000001)(26005)(82960400001)(71200400001)(38100700002)(38070700005)(53546011)(9686003)(6506007)(7696005)(83380400001)(966005)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: fnyDPXm+ELOoHe5cG6GaMDxGmd6s3LWKmYuqTSYUYrq9XCMK2HWI9Ga8h/Tsb1lW0WPiUmLyGhs2YmWulQ/dWASxFVMa1VOSPPKrpJaBw4ut1oYpZLIMP7LGunaY0GGOzyniXJgyvqHPduphTfP6kg4B8egExGF30/gpWXmIPodQidlX0SROsRmxV3Np1kPT+tVgEGCzCjC/JiNn6TNQTaV5/1rek/v1NjU0iLFrMzbexXrLUlMvoVbgIj7c3MP0Obkqcg1tETY4tjL7ZOo+JvMOCAVGT0DDKAekOSYhec23UCc1ejDTGQNJ8hlzCM1Bup8+oVykKfhsrae9Jmyb6lI01cmdf3hzeybvqdErSwfVQtBNdPNUS2SSaLR0IsZVNnsH0yeg+IVHERPNQdR2SEuCvW+z8+E2ye7AI6S4a/blhnMFjuDdHmcZ9eEN1Dtx79IXGFSJlSywmNIW8t79eLSFPjDfVAVsw3HtGe6l7AI+jpuEWV31RGxN4d33NMy238tHAb0JpaBj7aFIg7YlXtZ/q32JvsTwoFPAxN6Htn6ceiXHaPdTs5hNysaJZOOvU5r/4Bs4gm9Dfl4gsD4hyuIOPo5qaAckq7boSVpql140F4cxttKzOllG4YCtDYglUmhKSLRNkYiOTmMid4W5ONF5lFRd2ma3HbuN0YJXMyl1nnx4yEZjQ7X04DXZBKqTgRFOPMlLRf8jDRYtMyqB3Ebbgwoyk1XvkbZCgHOXsROVUQzyuvIs2JFkSL2JbnH8sYf6oVVhBosy6lacWmpR82Q+FoFoOBtDjwq8wM4HGoNi9oN9bebuBfzyO90iXfyE9C1ofhNymDKJ65cSUMYq/zia76IdNSVynWrPprkMWDutE9Lf0Y1l8rHzksr5OhK/+96vXIGsQ6V7hEdDvs78qF1i4Qru15wbIOZSuhamgsFsnPO6xGAgZ+TOth1BrW1g1AbI2AVTdvFiAhDL3++DUVo5t8MEb5eXnxjvRWHiJDKYkYIfo/x8Ra/s+/XdKlkvAQqLnvTY3QT1ujnxEGJk6Gmh02BDzNNE4nzaSx+MB0M37duPiuMnAy5jjU8ueZS5UnxMIOD+UAxND93bCP1iWUZcyLQnmotlYALcaH6dBtR1wav94xoK+G5mk83NXZwulLJ9GADHwjM3T4mu0IJdSlkV2pgd5CTtUS+wU3NUfQQ2MnCDNQmJfBg8wyJBWJbdWj+M3iEtrMMxBInhCLByvguYxfVOOYFEm25e8u+129slmjj0DNgddX8jMIqY4YAZG5cRj0yqCxPLPOlc+P30iZTe3GeUNr/ONrWGyPXV1RBHDL1zVox4+xCkLkPECEfXwOJxVhYus5W/s5ipligHSuhSMcd2fc8q0TSfJL5ipyYcrNE6l4XUuK5jCSzTIjB3JPt30e0rjni1XPq9BFqbVzAvmiGHqLf2Isv3L7dFoWzftaC0q2TeBH74EjlBxGUSDj3sQJ+wpJso6s5tXpcxNj01/o26/IcR3zDt+dozH23ibkOPuEHn9FW05F5FpyEtb3zZkaFMpcdf6G00M3KAxke9vElaZsTPvYoFomoOiBOHNosB4Cipt9AgzNaytyV5
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 172a4115-5318-4c79-13d4-08dbcbb9fccf
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2023 06:59:47.3621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7Lpfh3kuGbnK4YUH+jFaxC8zY55ObEXYxKwkTGkbEruYMp79JjU1r2ITu7mjeUtVvQIpGCVeJx1TFc1Rx7TsznLrbS9dvZMzBETwcbJR5nE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BE1P281MB2305
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ab85_6pzTgM3eMCMUoAyjr_5yz8>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Oct 2023 07:00:14 -0000

Hi Greg,

"EF requires and NQB recommends a mechanism to ensure ...."  That works for me, if a sentence is attached: Note that under congestion, low loss for NQB conformant flows however only results, if such a mechanism is operational.

I assume the mechanism indeed to limit loss to flows creating congestion in the NQB queue. As the queue is short, low latency will always result (for both, EF and NQB).

The other sentence should then again be clear too: in some cases, available rate may be 0 by config+loads, in others, it may always be above 0 by config and assign a benwidth independent of other traffic loads to NQB. 
EF requires policing at the configured reserved rate for EF, whereas in NQB traffic protection is recommended to operate at the available forwarding rate for NQB (depending on the NQB configuration, a guaranteed minimum rate may always be available).

These are fragments, I'll have at look at the draft, once you've published it.

Typos and mediocre English may occur...

Regards,

Ruediger



-----Ursprüngliche Nachricht-----
Von: Greg White <g.white@CableLabs.com> 
Gesendet: Donnerstag, 12. Oktober 2023 19:38
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
Cc: tsvwg@ietf.org
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate

Thanks Ruediger. This largely looks good. 

Technical correction in your second sentence:  NQB does not require such a mechanism, it only recommends it (and there's a typo, you meant arrival rate, rather than departure). I think there are a couple of options to correct this.  If the intent is to describe how NQB can obtain performance similar to that of EF, I think we could say something like: "To ensure that low latency and low latency variation is maintained, it is necessary for both EF and NQB that a mechanism be implemented to ensure ...."  If the intent instead is to further describe generally how EF and NQB compare, then we could say: "EF requires and NQB recommends a mechanism to ensure ...."  Since you asked that this comparison be added, do you have a preference?

Missing concept:  EF requires policing at the configured reserved rate, whereas in NQB traffic protection is recommended to operate at the available forwarding rate. 

Organizational comment:  We had discussed that this paragraph would land in 4.3, but we've now built up quite a bit of text that compares EF to NQB here, and it probably fits better in the Appendix, with just a reference in 4.3.  As a result, we'll need to ensure we're not duplicating material that is already covered there. 

Minor change:  rather than referring to "An operator", I'd rather this be generalized to also include nodes that only implement the NQB/Default pair. 

-Greg


On 10/12/23, 1:09 AM, "Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>" <Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>> wrote:

Greg,

while many of your statements are correct, they do not reflect the full picture. The text comparing EF and NQB needs to be clear and complete regarding technical properties:

RG
An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598]. Both, EF and NQB require mechanisms ensuring that the departure rate of the PHB's scheduler never exceeds the forwarding rate available to the PHB. The following caveats and differences apply: EF is typically expected to be a managed service, whereas NQB is not expected to be a managed service. The mechanism ensuring that the departure rate of the PHB's scheduler never exceeds the forwarding rate process differs between both PHBs. While EF relies on rate policing and dropping of excess traffic, this is one option for NQB only. NQB alternatively allows to re-mark and forward excess traffic by the Default PHB, rather than dropping it. Further, NQB recommends a flow based mechanism to limit the performance impact of excess traffic to those flows causing potential congestion of the NQB queue, whereas EF ignores flow properties. 

This statement is based on draft NQB and on EF. I accept diverging text, if any of my statements are wrong, misleading and cannot be backed by text of the two documents. 

I'll respond to other messages, once we settled this.

Regards,
Ruediger

-----Ursprüngliche Nachricht-----
Von: Greg White <g.white@CableLabs.com <mailto:g.white@CableLabs.com>> 
Gesendet: Mittwoch, 11. Oktober 2023 19:14
An: Geib, Rüdiger <Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>
Cc: tsvwg@ietf.org <mailto:tsvwg@ietf.org>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate


The other difference in NQB traffic protection is that it is recommended to be microflow-aware. I think the expectation with EF is that it is microflow-blind.


What I have currently is no change to the first paragraph in 4.3, but adding a new second paragraph in 4.3 which reads:


An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598] with the following caveats. EF is typically expected to be a managed service where the arriving rate of traffic into the EF PHB doesn't exceed the forwarding rate configured for the PHB, whereas NQB is not a managed service, and hence the aggregate of traffic arriving to the NQB PHB queue could exceed the forwarding rate available to the PHB. Additionally, Section 5.2 discusses the recommended handling of excess traffic in the NQB PHB, which differs from the handling expected in the EF PHB.


I can add a more explicit statement in the last sentence, something like:


Additionally, Section 5.2 discusses the recommended handling of excess traffic in the NQB PHB (microflow-aware re-marking/re-scheduling or microflow-aware drop), which differs from the handling expected in the EF PHB (drop without microflow awareness).


-Greg










On 10/11/23, 6:04 AM, "Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>" <Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>> wrote:
Greg,


Please clarify, is the statement will be included:


"Operators of nodes that support the NQB PHB could choose to aggregate other service classes into the NQB queue. This is particularly useful in cases where specialized PHBs for these other service classes are not provided. An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598]."


Regarding similarities and differences with EF, RFC 2598 says:


1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.)


RG: that has been settled, I think


2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate.


RG: draft NQB recommends a "traffic protection" ensure 2). NQB traffic protection works like a highly sophisticated shaper or a policer, but it serves the purpose of ensuring that the NQB schedulers arrival rate is always less than its departure rate.


Text NQB as is:
However, a QB microflow that is mismarked as NQB would cause queuing delays and/or loss for all the other microflows that are sharing the NQB queue.
To prevent this situation from harming the performance of the microflows that are in compliance with the requirements in Section 4.1, network elements that support the NQB PHB SHOULD support a "traffic protection" function that can identify microflows that are inconsistent with the sender requirements in Section 4.1, and either re-mark those microflows/packets as Default and reclassify them to the QB queue or discard the offending traffic.


RG: The difference here with EF is that excess EF traffic MUST be dropped, whereas that is an "or" to re-marking/re-scheduling for NQB. That latter fact is worth a statement "compared with EF, NQB...".


Regards,
Ruediger






-----Ursprüngliche Nachricht-----
Von: Greg White <g.white@CableLabs.com <mailto:g.white@CableLabs.com> <mailto:g.white@CableLabs.com <mailto:g.white@CableLabs.com>>>
Gesendet: Dienstag, 10. Oktober 2023 22:51
An: Geib, Rüdiger <Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>>
Cc: tsvwg@ietf.org <mailto:tsvwg@ietf.org> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org>>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate




See below [GW].




On 10/9/23, 3:18 AM, "Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>>" <Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>>> wrote:




Greg,




the proposal is




CURRENT TEXT: "Operators of nodes that support the NQB PHB could choose to aggregate other service classes into the NQB queue. This is particularly useful in cases where specialized PHBs for these other service classes are not provided."
RG PLEASE ADD: "An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598], Appendix A.3.1."




[GW] Ok. I agree in principle. I don't think we should reference Appendix A.3.1 though. That appendix has very specific performance numbers for jitter variation resulting from a simulation of priority queuing and WRR in one specific set of scenarios. I'm not sure that we would even expect an EF implementation today to provide similar result to that in general. 








To me, this statement is required as it simply acknowledges the fact NQB equals EF resulting from the NQB configuration and operation *in that case*. I recognize and accept, that doesn't expand to all NQB deployment scenarios, but it certainly is true with the above preconditions defined by draft NQB. I prefer the draft to be explicit to this point, as I don't expect casual readers to be DiffServ experts and I think it's fair practice to reference them to available IETF standards (and their references) helping them to understand operation of the DiffServ mechanism they may want to configure and operate. 








The above statements likely benefit from one more sentence, as EF recommends rather to drop than to remark and forward excess traffic. NQB recommends the latter, if the traffic protection mechanism is implemented. Please line out further caveats, which add to this, to enable technical discussion. 




[GW] Ok. I think the other distinction is that EF traffic is expected to be managed such that the arriving rate doesn't exceed the forwarding rate, whereas NQB is an unmanaged service. If EF is aggregated into the NQB PHB along with unmanaged traffic, the result could be different from a pure EF deployment. 








Regards,








Ruediger








-----Ursprüngliche Nachricht-----
Von: Greg White <g.white@cablelabs.com <mailto:g.white@cablelabs.com> <mailto:g.white@cablelabs.com <mailto:g.white@cablelabs.com>> <mailto:g.white@cablelabs.com <mailto:g.white@cablelabs.com> <mailto:g.white@cablelabs.com <mailto:g.white@cablelabs.com>>>> 
Gesendet: Donnerstag, 31. August 2023 01:44
An: Geib, Rüdiger <Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>>>
Cc: tsvwg@ietf.org <mailto:tsvwg@ietf.org> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org>> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org>>>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1 Primary Requirements, Forwarding - Departure rate








Hi Ruediger,








See below [GW].








-Greg
















On 8/3/23, 1:39 AM, "Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>>>" <Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de> <mailto:Ruediger.Geib@telekom.de <mailto:Ruediger.Geib@telekom.de>>>>> wrote:








Hi Greg,








Draft NQB section
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps- <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-19#name-aggregation-of-other-dscps-&amp;amp;gt;&amp;gt;&gt;>
contains:








"Operators of nodes that support the NQB PHB could choose to aggregate other service classes into the NQB queue. This is particularly useful in cases where specialized PHBs for these other service classes are not provided."








Let's assume an operator only deploys NQB and a Default Queue. Please point out the difference in operation between NQB queue and the EF PHB by referring to the experimental WRR EF implementation which is part of RFC2597, EF, by suitable text in draft NQB:
https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1 <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;amp;gt;&amp;gt;&gt;>








If there is no difference, please add text stating that "An operator only deploying an NQB and a Default Queue may obtain an NQB performance similar to that of EF, as described by [RFC2598], Appendix A.3.1., presenting results of a WRR EF simulation as a worst case EF implementation."
https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1 <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;gt;&gt;> <https://datatracker.ietf.org/doc/html/rfc2598#appendix-A.3.1&amp;amp;gt;&amp;gt;&gt;>
















[GW] Both EF and NQB can be implemented via WRR. In RFC2598, for EF the WRR weight is configured via a "proper choice of the EF queue’s WRR share of the output link with respect to its subscribed rate" and ends up being a "worst case" implementation of the PHB. Whereas in NQB the WRR weight would be set to 50% of the link capacity, and it would be recommended to additionally implement a traffic protection mechanism. In the very specific simulation conditions in RFC2598 Appendix A.3.1 (where EF traffic is limited to an average of 30% of the bottleneck rate and the WRR weight is 31%) the NQB configuration would be expected to provide better latency and jitter performance than the EF WRR configuration for marked traffic, but I think it would be misleading to make the statement you suggested without adding further caveats. Moreover, I don't quite see the point of it. Could you explain why you think such a statement is useful?








































[GW] for a response to the points below, please see the other thread https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/ <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/mCETQtmpiZtcLP6rLHvWpgbqFM0/&amp;gt;&gt;>








I'm not aware of any reference native NQB/Default configuration provided by draft NQB or by you in any separate mail. This may prove to be useful to understand configuration of an NQB Queue with the same forwarding preference (and hence the same likelihood of being deferred if other traffic is being served) as" the Default queue. I regard myself as pretty experienced in configuring QoS. I'm sure, less experienced readers appreciate information how to configure only a Default queue in addition with the NQB queue, respecting that "the NQB PHB cannot be configured with a rate R" (or anything similar to that).
















I'm as of yet only aware of two suggestions for an NQB implementations.
















NQB implementation status, text links to:
https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1 <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&amp;gt;&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&amp;gt;&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&amp;gt;&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&amp;gt;&gt;> <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=79935977-877b-4027-8f6f-7d739945e1d1&amp;amp;gt;&amp;gt;&gt;>
















I found, which specifies that "conditional priority is given to the Low Latency Service Flow" - that is the NQB traffic. This is astonishing as a reference implementation, taking into account that you so far claimed that NQB is definitely not about priority. I also note, that implementation is suggested by a WRR scheduler:
















CM-SP-MULPIv3.1-I25-230419.pdf
Page 289 ff
















Which contains:
Inter-SF Scheduler: CMTS mechanism to identify the amount of resources that will be allocated between the Low Latency and Classic Service Flows that belong to the same ASF.
















From there I take:
7.7.3.2 Inter-SF Scheduler
As the Dual Queue Coupled AQM architecture provides only one-way coupling from the Classic Service Flow to the Low Latency Service Flow, it relies on the Inter-SF Scheduler to balance this by ensuring that conditional priority is given to the Low Latency Service Flow within the ASF. “Conditional priority” means that traffic of the Low Latency Service Flow will be serviced with a priority, yet without the Classic Service Flow being starved. Weighted Round Robin (WRR) is a simple scheduler that achieves the desired results, and is recommended in [draft-ietf-tsvwg-aqm-dualq-coupled].
















For Downstream ASFs, the CMTS SHOULD implement a WRR scheduler between the Low Latency Service Flow and the Classic Service Flow within the Aggregate Service Flow.
















##########
















Apart from that, I have suggested a pseudo native NQB/Default scheduler which can be configured by routers of one commercial vendor, see
















https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/ <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&amp;gt;&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&amp;gt;&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&amp;gt;&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&amp;gt;&gt;> <https://mailarchive.ietf.org/arch/msg/tsvwg/08BwyTAe0glWvIApQB-eaPuA_V0/&amp;amp;gt;&amp;gt;&gt;>
















Feel free to suggest corrections for the latter to clarify NQB deployment for equipment of this vendor.
















Regards,
















Ruediger
































-----Ursprüngliche Nachricht-----
Von: tsvwg <tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org> <mailto:tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org>> <mailto:tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org> <mailto:tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org>>> <mailto:tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org> <mailto:tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org>> <mailto:tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org> <mailto:tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org>>>>> Im Auftrag von internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>>>
Gesendet: Mittwoch, 26. Juli 2023 19:08
An: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>>>
Cc: tsvwg@ietf.org <mailto:tsvwg@ietf.org> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org>> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org>>> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org>> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org> <mailto:tsvwg@ietf.org <mailto:tsvwg@ietf.org>>>>
Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt
































A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Transport Area Working Group (TSVWG) WG of the IETF.
















Title : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services Authors : Greg White Thomas Fossati Filename : draft-ietf-tsvwg-nqb-19.txt Pages : 29 Date : 2023-07-26
















Abstract:
This document specifies properties and characteristics of a Non- Queue-Building Per-Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best-effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue- Building microflows.
















[NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.]
















The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;amp;gt;&amp;gt;&gt;>
















There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;gt;&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&amp;amp;gt;&amp;gt;&gt;>
















A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;gt;&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&amp;amp;gt;&amp;gt;&gt;>
















Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts