[tsvwg] NQB PHB description and assumptions

<Ruediger.Geib@telekom.de> Fri, 06 September 2019 07:12 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 73DCE120088 for <tsvwg@ietfa.amsl.com>; Fri, 6 Sep 2019 00:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.288
X-Spam-Status: No, score=-4.288 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q6D2xP5nF3Iw for <tsvwg@ietfa.amsl.com>; Fri, 6 Sep 2019 00:12:56 -0700 (PDT)
Received: from mailout31.telekom.de (mailout31.telekom.de []) (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 7562112002E for <tsvwg@ietf.org>; Fri, 6 Sep 2019 00:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1567753971; x=1599289971; h=from:to:cc:subject:date:message-id:mime-version; bh=PUabjY/WgxPyxeYAPIg0EZV/zl+u7sfVMSO/vR6+fCM=; b=iEvxy7XXHXg9BqheA8cQcwnKdRK6hzs6SDNgCuO6XBGIxGpyQsx5MYZS wCBx42Z0qIvA+v/eoAL8dEuBkfTdmBXDTzh+5eZVc+tY05Ka0LmMzNB6M mmrq+bEiV/8zdIL7/DAkbuFyjbHpkXlwEIetxhxFezUAvzVQyuxd9+ei+ 5Gn1wc6fNukr0HQwhGSzLrSd/qu/jSW23+jkglv0KS1CznwslZxS9X8en aDkJYr0YY9SYfQRQk3neuN5vn6HarbDLrJvAKUdCWj0E2wgR6j/VbKlnt ATawe/YKYpZj0jKQmum0JUn+RK4yCnvNLqyjMo4VhpfDbLwEgJAXEfDsc A==;
Received: from qdezc2.de.t-internal.com ([]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2019 09:12:47 +0200
X-MGA-submission: =?us-ascii?q?MDHnXivTAPZeF3iNQQGMUxRRM78kV5WqaZEN8r?= =?us-ascii?q?gCJ2WQSFn+J1ccLSU0XRt/bj2mNwLSOC8wx/JVH3VNH8zdQbs+flyTJ1?= =?us-ascii?q?8l+xx2OPD+funsR1g3dw2IzJSitoNpTdXpKQU2Vpqt5K7HKGyM2LvWT+?= =?us-ascii?q?ahlLmwLPJl02ie+DVs3ZGvrA=3D=3D?=
Received: from he105867.emea1.cds.t-internal.com ([]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 06 Sep 2019 09:12:52 +0200
Received: from HE199743.EMEA1.cds.t-internal.com ( by HE105867.emea1.cds.t-internal.com ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 6 Sep 2019 09:12:51 +0200
Received: from HE100181.emea1.cds.t-internal.com ( by HE199743.EMEA1.cds.t-internal.com ( with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 6 Sep 2019 09:12:51 +0200
Received: from GER01-LEJ-obe.outbound.protection.outlook.de ( by O365mail02.telekom.de ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 6 Sep 2019 09:12:15 +0200
Received: from LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE ( by LEJPR01MB0330.DEUPRD01.PROD.OUTLOOK.DE ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.20; Fri, 6 Sep 2019 07:12:16 +0000
Received: from LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE ([fe80::987d:70fa:4d72:d6da]) by LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE ([fe80::987d:70fa:4d72:d6da%5]) with mapi id 15.20.2220.024; Fri, 6 Sep 2019 07:12:16 +0000
From: <Ruediger.Geib@telekom.de>
To: <ietf@bobbriscoe.net>
CC: <tsvwg@ietf.org>
Thread-Topic: [tsvwg] NQB PHB description and assumptions
Thread-Index: AdVkfBP29FODUeIhSciHo/YcUWQEYg==
Date: Fri, 6 Sep 2019 07:12:16 +0000
Accept-Language: de-DE, en-US
Content-Language: de-DE
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 653df8af-4a7c-4c95-8d81-08d732998c55
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEJPR01MB0330;
x-ms-traffictypediagnostic: LEJPR01MB0330:
x-microsoft-antispam-prvs: <LEJPR01MB0330AC80269C0363BB666BD59CBA0@LEJPR01MB0330.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:3631;
x-forefront-prvs: 0152EBA40F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(346002)(376002)(39860400002)(199004)(189003)(14454004)(186003)(26005)(3846002)(102836004)(476003)(6116002)(790700001)(486006)(478600001)(2906002)(53936002)(7736002)(8936002)(81156014)(81166006)(4326008)(8676002)(19627235002)(6916009)(9686003)(316002)(256004)(14444005)(71190400001)(71200400001)(85182001)(54896002)(66066001)(85202003)(55016002)(6306002)(86362001)(33656002)(66574012)(7696005)(76116006)(66946007)(52396003)(5660300002)(64756008)(66476007)(66446008)(66556008)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0330; H:LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 343bmRg7nTxqUq6YpjR18MJf8Zkxn8Z/uQRg5LRW81VtAOUH9t/NRP3yiBnXl0KoQIywaOP2+cGHVa19P1norBQoSmrO1gXBhDC9wJczJXiRa6L/K8uwXMf+bGEswYKSxBSW3tpmhJEXUBkRDq0IKlKwjkfHCA5UwaC1kTAYACzyROPTGeiiOZ/eogGJU+fDEy3KzFrTCwXAkscqLeRf9XWdSh3x6DXtbyTSeA/zjO0QvZmYAwbQOKgzbJ+yJe+8Tht6Lm88syQzbuCnM7qEYRGFUewWDw7qpCngPWWr6vse4dAq28WcnXUlvGf+vdwFWcxRa4lFtTBi+wcwuu3GbCMp/PI6eludeEGkbA1sTb0XWbjaNE9YqVlG9gGfu8rAn9jHJUSCt26PNl8hsnoqG//IfjQ2cT1Rwxy2wrP6vTc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_LEJPR01MB11783FACEF3688ED3986EA6C9CBA0LEJPR01MB1178DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 653df8af-4a7c-4c95-8d81-08d732998c55
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 07:12:16.1366 (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: ugrH1dFO3yzwaRBh3ux7aLNVMyrQW5bj69Zz7x9x+ejk5++9orreS6GT+zIhRFB8DVQcqwWYo9MLlVoS4hUw/YwVBWgSxvngvw0wRWrNAAc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0330
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/H8uRDWeuA_HPfpl-ttpsI1p4seE>
Subject: [tsvwg] NQB PHB description and assumptions
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Sep 2019 07:13:00 -0000

Hi Bob,

the following excerpt of your reply to David and Sebastian contains text for which I couldn’t identify a clear reference in the NQB draft. You ask the authors of that draft to add a description of the scheduling. I agree with you and like to expand that to a description of the PHB so that a reader has an idea about how to implement or configure a NQB PHB beside the default PHB.

What the NQB draft doesn’t mention, but you do:

  *   You state NQB doesn’t require priority queuing (the NQB draft suggests to operate EF and NQB via the same queue with DSCPs 101110 for EF and 101010 for NQB, which to me means, it’s traffic destined to a priority queue).
  *   You state that NQB is enabled largely by high bandwidth Internet accesses. The NQB draft doesn’t.
  *   You are quite specific with one possible requirement, which in general would be that a maximum length PDU should be serialized by a link suitable for NQB within less than 1 ms. The NQB draft doesn’t say so.
  *   Further, your example suggests a 3ms@accessbandwidth buffer depth for the NQB Queue. The draft is not specific here, and it likely doesn’t have to be that detailed. In my eyes, the draft NQB PHB description is vague. I’m clueless how to implement or configure an NQB queue, if I read the draft.

I’d like to add another point: if, in the example below, the NQB traffic stays below 50% link utilization also in the case of access link congestion, it shouldn’t see a queue.



Please confirm that you (both) understand that, with NQB, the low latency is not provided by scheduling in the network. It is primarily a property of NQB traffic sources, and the only necessary property of the network's per-hop behaviour for NQB is to isolate NQB from QB traffic (i.e. in a separate queue for the NQB class). There is no priority scheduling requirement.

[A comment I would make to the authors about the draft: it needs to give some example approaches to scheduling between NQB and QB, or at least talk about this scheduling.]
==Incentive Alignment?==
Background: NQB has become possible largely because Internet access link rates have typically become fast enough that the serialization delay of a packet can be sub-millisecond, and therefore a queue of a few packets introduces delay that is small relative to other non-optional sources of delay like propagation. In these cases we no longer need priority scheduling for low delay.


  *   Scheduler:
     *   WRR with weight 0.5 for NQB on a 120Mb/s link. That gives at least 60Mb/s for NQB flows.
     *   Scheduler quantum: 1500B.
  *   Buffering:
     *   The NQB buffer is fairly shallow (30 packets or 3ms at 120Mb/s).
     *   The QB buffer is deeper (say 200ms) with an AQM target delay of say 10ms.