Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - BBR

Ruediger.Geib@telekom.de Wed, 02 August 2023 06:25 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 DD4D2C14CE52 for <tsvwg@ietfa.amsl.com>; Tue, 1 Aug 2023 23:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Level:
X-Spam-Status: No, score=-7.103 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_HI=-5, 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 Jdmp9B0Sam9L for <tsvwg@ietfa.amsl.com>; Tue, 1 Aug 2023 23:25:54 -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 19325C1519BF for <tsvwg@ietf.org>; Tue, 1 Aug 2023 23:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1690957554; x=1722493554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0LGdID/YdnR602jSGfP49PtpPg2PY5og+7MY3UeiTjc=; b=DHYikaqVnAo6k1XEwVG9Z1jmdGg2gSkbVQy21XwqwTcpZNmY2gEM+gd+ tJ0NRDy9kRBP2O9NTbF8vFjoCofgtmw6uXS3lllIerbTNL+B8DB+5rqLS Ea7cqDfiJb0+T7+9jNFPu614PDSS9BX1End/Ck53x+WqnSUL+FkkVF5dC XxXJ43Cu/HSq8K6LFdIQsCsfPQVtTbiF2b/VIcTwyC0SA3CZ7Y/Ek0h5g ZZDU6YUuutZ8C/8mdVpEWvcrROBewbla0N+h2bEeuoRk0oZtKRvik7J76 eQ5nUyIehNGxX1vZaYigW4BpUuVUX8ueK5ytdRL8AoIfFuHgeCyprq5p4 A==;
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; 02 Aug 2023 08:25:50 +0200
IronPort-SDR: 64c9f6ee_/rNMYErnM9zhtpoXDc6mrCN//eXU6rpqKRtyNUlUG5MYRft LiD8EnM7aLF4bcg9mA5ar1dvtyLppFCWYZZgUcg==
X-IronPort-AV: E=Sophos;i="6.01,248,1684792800"; d="scan'208";a="739590516"
X-MGA-submission: MDHOkHKFzIzPKAQZrV/1vjpQct691P/EpGMKRB9hZewHg0u0qhBkFRk1tcWOtx9rv7XCHlayv9YzcmUkh47gb87RoPwFZpHEowFJsjvrJIM0F/RuzfsLPQd5tNttHhZ5Li+MSmi0J2jSG8zvf8ktHfkcLd4XDR+GrjUlUm2c6vzr2g==
Received: from he101421.emea1.cds.t-internal.com ([10.169.118.197]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 02 Aug 2023 08:25:51 +0200
Received: from HE126304.emea1.cds.t-internal.com (10.169.118.205) by HE101421.emea1.cds.t-internal.com (10.169.118.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Wed, 2 Aug 2023 08:25:49 +0200
Received: from HE102771.emea1.cds.t-internal.com (10.171.40.43) by HE126304.emea1.cds.t-internal.com (10.169.118.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30 via Frontend Transport; Wed, 2 Aug 2023 08:25:49 +0200
Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.174) 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.30; Wed, 2 Aug 2023 08:25:49 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IzZIxIQAyf8+YSEIqO2Pq+duYV7mHoVY0IPRRQ/hyZoefX0wZgqgh9yEbTw/5xH+5QDTw2LDA07i2/6VKTzWiuKLIvUpgVR6urMthlK/T//AZt0y69HMnv0wdI4JAjlsMfOzkka+30j8oFHw29ogKCOqPI4zGHete5yNI1+68O+TxqDHj1DDIENEVyThFiYguHyUiZDxZbeucIMMQOZTfiLC+l/Mm5x6mQqmKbPg3Y7GImfC9KYzMOArFkzDh27r/jz2i7ER6yJqfHSQ5XPxCPTjBFuoNdhyD8E+6APTVdp5iWLtsQN8XWjhZ8zhXa3UP6C2rxGAxitH62oFokTaGQ==
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=0LGdID/YdnR602jSGfP49PtpPg2PY5og+7MY3UeiTjc=; b=egZMUpCEpbcDJ8nFo3WFv66VeCSHv2UAXbcBdEY3DAbuD0yG9fpsjksvlLfXl7LFnFYNpraR1pjSWj5eM7jCuX5rPFEgxzpqiqOk5f79dXrtDJ/6K3kglE64cbZUQO3EK9wYisLlO/i2k3dqvrTRRwzg3riPfE+jiyKm5trxDjh5eYc4FRvivKQfvSekLsWnUqNXRfNPaS55CVMVRdfNh6d7gOXrlbQaHW/plaQxIJX1VMGVbFbd+tvPLyNgGyxsqyJFMzJaIjdo/hjUdC9k30oKv+n8oEvODkY8gzhK1juaVi0nRW+KEPDVD9B2w2UTIwqlSL92lmpZTncyOMbeZQ==
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 FR2P281MB2170.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:3a::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6631.45; Wed, 2 Aug 2023 06:25:48 +0000
Received: from FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM ([fe80::89d5:3015:4aea:b26f]) by FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM ([fe80::89d5:3015:4aea:b26f%4]) with mapi id 15.20.6631.045; Wed, 2 Aug 2023 06:25:48 +0000
From: Ruediger.Geib@telekom.de
To: roland.bless@kit.edu, g.white@CableLabs.com
CC: tsvwg@ietf.org
Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - BBR
Thread-Index: AQHZxIHDsmwmJVDXgUyOHYQKL7jtHq/VgsiAgAEFpHA=
Date: Wed, 02 Aug 2023 06:25:48 +0000
Message-ID: <FR2P281MB1527709C65666E3DC213990D9C0BA@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM>
References: <169039129927.3244.8784605239288349316@ietfa.amsl.com> <FR2P281MB1527340CD1B283FF32161DCC9C0AA@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM> <2201ba11-c247-35f6-d127-1c912eeed66e@kit.edu>
In-Reply-To: <2201ba11-c247-35f6-d127-1c912eeed66e@kit.edu>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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_|FR2P281MB2170:EE_
x-ms-office365-filtering-correlation-id: 46665ee5-5f60-4edd-15f5-08db93214fbd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gJbjx7jzJsn1dW5SKBU105cAODAgd6Hs6vMd5o3EBspiYINKpFrjOlBYcP/zUi7cKeIgfT3VqF9LG/vh7njfL2kljpsKEhHxQ+euTzBwU3XtNX7Hxh1QMo63cYlW09yYLN8GqfVt2p9SHqw4b9GvFNjk9DsFnkDLtg54zNmXALJi47xMywBuVcPpDLDpT6n5Jay5RKZIaPNs7P3DdcFzibRHY8do5qy8cZV3GecFUysG73CP2bukJwOamZ5ssmpu6p1/WWahVnmWdKbbKU6u6RFR56LZecyWi8cJVSngOUeBMSGXuz8er9XnLzb1729o7Gwu92ccmt+Wndru72IGxLwPBbO2ui5yYRJmx/1dGB6uu4wWg59ZMh9++CZk3P1SGQvqbY1ZDkKDkH4SPTIs9sUoAbn7MaKcpQ1Q4AbaxRyTaTJjLS23fCHuZmbvjYQTNuCsuawTs5qa4taO/wz/P4fh0jF+ZOPBs9gQse218+qtXfxWBIlgi5Ui2RTNNHG84cacI+1zkOzIM4heLVOO93HflimAnyeB/QZaHv7sPX8a0xs91RqmIqU4zzOUCD93zw5s2OUU/INor9DVT44+7vL/DK6EOei4iTAyLV+vRe+OBwuxDuJqZexHgT+ajuPy9IK9LQs9KPb33hqrD9WKhSJ2gojv/1tlmlNxszLKkTyTuczYO6lAi9rIk/iTp48G
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:(13230028)(136003)(376002)(366004)(39860400002)(396003)(346002)(451199021)(1590799018)(122000001)(53546011)(6506007)(26005)(38100700002)(82960400001)(186003)(38070700005)(66574015)(83380400001)(2906002)(85182001)(85202003)(52536014)(5660300002)(33656002)(8676002)(478600001)(8936002)(110136005)(86362001)(9686003)(71200400001)(966005)(7696005)(41300700001)(316002)(55016003)(4326008)(66946007)(66446008)(76116006)(66556008)(66476007)(64756008)(1580799015); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: urUQcL9YM+L5gEYT0jZpcXoP5eiMNYvhDdKB3iOHnnPuf+wdogVockLKLyzA4vQ2JSaM1y1pm0A8NOgUeQSpJF0MHEWnCdkQoJ3Hm4BVtlkJKE0cQxmtc7tIczAt8pEqak3X4C2iie+nZfXRUFphVv4BXMtODrhQYPVg4WrccNkrme55GeGb3c6JoZTeh8UIsF2frho/qBQ+J/aGlRMhnOH9xoUb/emDfxn8eAy+2EMj0y6yUeteBpgedzJgTgEWh+XkTlQtlxZvTFoI8YVJ2PAwCCqrgXOm+eTk2hCUxpvcYnH98NkA4BtFSnhCGH4z5zsgnUbeapCP29RVxe1lJPfWka6y8Xh8auInyVDZ3XYpi+mZOGq/KAwhDBny9T3+IZcQcbgSt6T+Hs231C3ScTpRkI68MR57NRBtTuobU1YVRqq9/TU/N9/kIKrd3CZxfnwBOY082PEy8UdO7gKJIyPY1zMBgXr2AJ4D0Rxzts/uWKHUKY4XAPg+e3TwosrY2USTufnh1cWagTYkVIylq6hIlN+ZibuMmZ5/jYpzTV1Y/EbjRSGok5zQ+Lp+Z/KkoXXKb2lXAq6mtN2CRmPw2/vdcRRFHLsy5R34hd7iaetqlT/tnYbefDELn/817QwoEvHirEiZH4E93xMMibH5cVm1jDEnOo0KzoA4IPGjacWQyzFOflRsjzZNedMYIOxjDZy9LSihrJdg032wkyeh9e+O8e0RWKs+KERrWoLY/FYpl5iXiLCkg7k6CxTFLZmKj2sruh3z61mRiWpMEPOMW4VyHdelnsv5HbhGBGjsKhgrQ0FjFmBtNWDiYdWQEEXKqyipJuyQ2qAIWsVMo2UNx3gYJhzmDLGzL5JW/p4R6ZcKw/HeyVTiGtlIfqbL4tQ5i4Rsa2FLJFElxwQ+TKowCFFwmOuBd7vEIyUsnHeI8lEEnrHjfG94niGImEkwRJWChIJ6degXr3i992gRMMrmWYdiPjm4XPwSIHA5txADzcQXSPBkAV5lxhBwhhLb9hW08xzJCfGpIF5ClbJOVPk7Y8rlrXjN+Pj5z4t1DrAScIs5VDj3c+2Trd2ezl9xRtGSK30rGjW9kg5VmaskFU1GCLqbH1mqd5RjOJFigku0dcCCsJtx47PbZx1SqOHXZ4chIJboXWYGHoufWjQsbVybH+GhJG/9hNQHPxx8U/bgjcWnHgyi9VCA9gs4E862ZbkpRy2jfXppaCgeQRAKitSVzbKi13PSz99bzhhY36b6bCh2u1rOmdFl/6rBZ1xfP4o+Z2OEcyFXyyUH/beRwSsFX3egBf3SJ6sq/KdZsGXxV2mTbJrb/Z1n5nRV8unniWWrTA6b1onCxkfJZdZ8ZA91jiYPx3WOe2/Rh7wtkJLdMeYge/MfqhMSKw+8nsOH3UkT2ujFKQW3l/QsFHLA79TBnijBlts9tc0hXLlcSxe6h50v6hDUsLsz7ZPNI24AYSJr11C0SXb/JCiWc74n63FyvMB//zjt+Bit76xshtfCHET+36VycxI0O7rRvLMwbK39jy9WWRFB6OUbWNzRfZ8mkP3GuCeclkJmaSj6pO8CvZvYUUjRA2JsTGp4aLadwN6S
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: 46665ee5-5f60-4edd-15f5-08db93214fbd
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2023 06:25:48.3635 (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: s30eBY/0AlL5Z1Ix9V0bUfg9EQoStpyKUHmbx3mLAGhsjfWhz2uArTddxABGAhisXwB7cM3j8cxTVv4iNVAASK3c5l940NbPYzRVN/ua5Kk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB2170
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cUg2hIiXUsDPdHQm_BM-imOtTIk>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - BBR
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: Wed, 02 Aug 2023 06:25:58 -0000

Hi Roland,

thanks. My point is, draft-NQB claims BBR to "generally overshoot the available capacity, causing a queue to build up at the bottleneck link". This contradicts the BBR design aim, as formulated by the BBR authors "..without causing excessive queue pressure", and it seems to contradict a statement to be found within an RFC co-authored by Greg too. In the NQB draft, Greg puts down a negative evaluation of BBR, but does neither provide a reference, nor measurement results backing his assessment. A non-informed reader may take that as whatever BBR claims, they failed. I'd expect a reference for statements like that at least. Or removal.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: Bless, Roland (TM) <roland.bless@kit.edu> 
Gesendet: Dienstag, 1. August 2023 16:39
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>; g.white@CableLabs.com
Cc: tsvwg@ietf.org
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - BBR

Hi Rüdiger,

I brought this issue up on 2019/09/13 already (see "Comments on draft-white-tsvwg-nqb-02" 
https://mailarchive.ietf.org/arch/msg/tsvwg/OY6yFWNUGxukDOwvpMP1FuokiyE/
for reference). In general, capacity seeking does not automatically mean that it is queue building (e.g., TCP LoLa tries limit its queue to 5ms, but it is capacity seeking). BBR cannot always avoid to build a queue, but tries to limit its length, too.
As far as I understand the NQB design and draft, NQB flows are application-limited in nature (and thus not capacity seeking), so neither BBR nor LoLa flows are intended to use the NQB PHB.

Regards,
  Roland

On 01.08.23 at 16:09 Ruediger.Geib@telekom.de wrote:
> Hi Greg,
> 
> Your draft NQB characterizes BBR as a capacity seeking protocol...causing a queue to build up at the bottleneck link (see below). This is seemingly in contradiction with the design aim of BBR (see below). Further, RFC9330 lists BBR as a "scalable congestion control" based protocol (see below). I note that the latter is co-authored by you. I take the statement of RFC9330 to contradict the standards track NQB judgement of BBR. Could you provide a reference or text explaining to readers, why your latest standards track RFC judges BBR as Queue Building? Alternatively, you could remove BBR from the statement in draft NQB.
> 
> Regards,
> 
> Ruediger
> 
> 
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#name-intr
> oduction Many of the commonly-deployed congestion control algorithms, 
> such as ..... BBR, are designed to seek the available capacity of the end-to-end path (which can frequently be the access network link capacity), and in doing so generally overshoot the available capacity, causing a queue to build up at the bottleneck link.
> 
> https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congest
> ion-control#name-introduction-7 BBR uses recent measurements of a 
> transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path, including its estimated available bandwidth, bandwidth-delay product, and the maximum volume of data that the connection can place in-flight in the network without causing excessive queue pressure.
> 
> https://www.rfc-editor.org/rfc/rfc9330.html#name-l4s-architecture-over
> view Indeed, between the present document being drafted and published, 
> the following Scalable congestion controls were implemented: ...., and the L4S ECN part of Bottleneck Bandwidth and Round-trip propagation time (BBRv2) [BBRv2] intended for TCP and QUIC transports.
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von 
> internet-drafts@ietf.org
> Gesendet: Mittwoch, 26. Juli 2023 19:08
> An: i-d-announce@ietf.org
> Cc: 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/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19
> 
> Internet-Drafts are also available by rsync at 
> rsync.ietf.org::internet-drafts
> 
>