Re: [tsvwg] Traffic protection as a hard requirement for NQB

Greg White <g.white@CableLabs.com> Fri, 06 September 2019 19:53 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 2D797120C97 for <tsvwg@ietfa.amsl.com>; Fri, 6 Sep 2019 12:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelabs.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke77fP5imT7J for <tsvwg@ietfa.amsl.com>; Fri, 6 Sep 2019 12:53:53 -0700 (PDT)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::71c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2650120C4C for <tsvwg@ietf.org>; Fri, 6 Sep 2019 12:53:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gbLQCM/XJhr2o5KYX5TgRhz6QOCOP40nLKYz2UgJEMc0aNSFDTFv1k9ln/LvmHbO2ju7OhcLSubjTfbcsQh5IAj+Vt0QY0P8yg3JNsDhwSGH00RkW1x29UgQCxE+VsqhoaT62Eeme/oXJFmz0u4GWLsSvw5lY5035UNLb4FsVoeaMCR+C1skvHzjyy2FealPv1PBaJAzTNPuiLRM3IkIlBbVn3UtNX5kBcshu1rMpO6y+36MeQati07L/7eNRNGuN2rdpgfeLFf9wE/E6Dsl2NMQsCttMD2AtFH6DaqjUF1rzxDHGEuG2YuBeDbL6WRTXu/miiRBsQ6X0FYNOuvfDg==
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-SenderADCheck; bh=PEX7NGz432ksezoeM0RvrwgPzNuNnudITi4V5aTm8Rw=; b=L2PuIS5mRcRv5dqHge/MF/S+xat3YAIJUIcNxrJgHxhqu63qDP9/dtxRT8aObzq0BBHQdAAV3YdVAP1gDgkCWQQb1r+MxYpgDpZoSCYjTmnXqIUNrP9ZJ45KneH+Q76ryIdYoyhb1O3t/EYvSxnFTDWTcDHaYeqdJhkxlBNUHm8/vmVQ1kHd/5BDaUr7tXPNoxw/fZOHWGOyyoV71Kg46G+MLasxOSmTmLN0xxcCTQANyaTzuIMPKSPK3+R+ASG+w4xrApK7KMEBP03DAMR5XTy0Zr4VGJlRq2CsnwYO26+fPTXc62wF/gxr/dnsSAUs+/8ZSOz3xEqsjIhCtlFM+w==
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=PEX7NGz432ksezoeM0RvrwgPzNuNnudITi4V5aTm8Rw=; b=AwXujAbbpzLBYfhiyrTtftodh6E/+W6Ez5gvPtRAahizV8HUY4VoxpnlpwDf9s8qiVSIJPAr8Kgi9W9CZ1LebxOllNQXkV9nLZSkQebPpND/E7OoZRK81pUPqe41y8PfCJ03xrd/+mpGWUv/QlfsbDQmn0VZfulzli9WEeaZH70=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4749.namprd06.prod.outlook.com (52.135.117.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Fri, 6 Sep 2019 19:53:50 +0000
Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::cc2f:14c9:624d:4e74]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::cc2f:14c9:624d:4e74%6]) with mapi id 15.20.2220.013; Fri, 6 Sep 2019 19:53:50 +0000
From: Greg White <g.white@CableLabs.com>
To: Steven Blake <slblake@petri-meat.com>, Bob Briscoe <ietf@bobbriscoe.net>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Traffic protection as a hard requirement for NQB
Thread-Index: AQHVZBcbAE9WSYnLSUuE4vuQINlztqce+66A//+xKIA=
Date: Fri, 6 Sep 2019 19:53:50 +0000
Message-ID: <E865FE52-36AB-4B5F-A4FB-A7B946A33CA1@cablelabs.com>
References: <CE03DB3D7B45C245BCA0D24327794936306BBE54@MX307CL04.corp.emc.com> <56b804ee-478d-68c2-2da1-2b4e66f4a190@bobbriscoe.net> <AE16A666-6FF7-48EA-9D15-19350E705C19@gmx.de> <CE03DB3D7B45C245BCA0D24327794936306D4F3F@MX307CL04.corp.emc.com> <50404eb0-fa36-d9aa-5e4c-9728e7cb1469@bobbriscoe.net> <1567794961.7634.64.camel@petri-meat.com>
In-Reply-To: <1567794961.7634.64.camel@petri-meat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com;
x-originating-ip: [192.160.73.16]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 58e42224-a20c-4f1c-1a61-08d73303f075
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR06MB4749;
x-ms-traffictypediagnostic: SN6PR06MB4749:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <SN6PR06MB4749F901F4F68A916F7F17FBEEBA0@SN6PR06MB4749.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0152EBA40F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(396003)(39850400004)(366004)(189003)(199004)(71200400001)(71190400001)(4326008)(486006)(14444005)(6486002)(76176011)(446003)(33656002)(54896002)(66066001)(102836004)(81156014)(81166006)(8936002)(99286004)(26005)(6306002)(8676002)(25786009)(6506007)(110136005)(11346002)(76116006)(186003)(2616005)(6436002)(66946007)(66476007)(66556008)(64756008)(66446008)(58126008)(91956017)(6512007)(7736002)(5660300002)(53936002)(2906002)(14454004)(478600001)(229853002)(316002)(36756003)(86362001)(6116002)(3846002)(476003)(6246003)(256004)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4749; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: f1wLAL4w15L55j5ldgPDKYJavkWTiIqUt1Ys9Dci/fAEs1XasoTGle7lq0d3x55mA7jagEa9Ez4Ox0oAZ243PEWd57SAwzIFQnFycZkCKOaEz5kohZovndKxRS6JlOuK6XK3jnubVzp7yewehbpf/nWjudyxTKpdp9NFjSQMqJitVAjyRLL/975ZsdHmI6t/BICk5YvykqpOxy4GFEjLSQ0bFyBAACoLqf5B8OBgJ6FybeMdKdpdkfsXBJd28DSE6AJ6KML4ruQA/2t0GoAxoLUGzg7mELheQG/BbPjn9zoOfQ5Azx4a8dwTDzSOqnobXrzcAn1vKdoKqgwe7rLpu0r5o1rcXKIyVpNsOCO/249vXT5T6GfHD8kuRo/e/gu4Qb5dJqS19trUjrtAr20Wc46rRzsdFaTCH8HpfXb/txM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E865FE5236AB4B5FA4FBA7B946A33CA1cablelabscom_"
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 58e42224-a20c-4f1c-1a61-08d73303f075
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 19:53:50.6080 (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: kRAczKAdTFPisD1b6y9LgYb2G1H0PNGMb/jN4mI0CNO3qTJhPG6RCNvPthWJ1c9s928R4kMLWx4w99ZbwQA0kQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4749
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/6AQM7AKXi1SJbTGBykGX0fbj31k>
Subject: Re: [tsvwg] Traffic protection as a hard requirement for NQB
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 19:53:57 -0000

[GW] comments below

From: tsvwg <tsvwg-bounces@ietf.org> on behalf of Steven Blake <slblake@petri-meat.com>

The objective as I understand it is to offer low queueing latency to non-admissioned-controlled/non-capacity-seeking traffic (NQB). First, this is only feasible if NQB traffic is naturally self-limiting to a small fraction of total traffic (e.g., < 5%). Second, existence of this NQB service should not noticeably impact the QoS of capacity-seeking (QB) traffic. Third, implementations of this NQB service should try to ensure that capacity-seeking traffic trying to utilize the NQB service gets worse service with very high probability (so that it doesn't even bother to probe).

[GW] If the WRR weight is 0.5 for each queue, then it is feasible for the NQB PHB to provide low queueing latency to NQB traffic up to 50% of the total link capacity (and more than 50% when QB traffic is not filling up the other 50%).

[GW] On the second point, you are correct, the existence of the NQB service will not noticeably impact the QoS of capacity-seeking QB traffic.  For example, if the NQB traffic did happen to be smooth traffic (CBR) at exactly 50% of link capacity, then with NQB, the QB traffic flows have 50% of link capacity to compete with each other for. Let’s say that competition results in (e.g.) 0.1% packet drop/mark.  On the other hand, without the NQB service, and in the presence of the same CBR flow, the capacity-seeking traffic flows similarly compete for the remaining 50% of link capacity, and settle in to the same 0.1% packet drop/mark rate (yet the CBR flow is unfortunately also subject to high queuing delay as well as 0.1% drop if the link doesn’t support ECN).  Well, being picky, if the link didn’t support ECN then I guess the capacity seeking traffic would compete for 50.1% of link capacity without the NQB PHB, as opposed to 50% with the NQB PHB, but I would argue that isn’t a “noticeable impact”.

[GW] On your third point, I agree in concept, and it is an aspect that we’ve discussed privately several times.  At the end of the day, we could not convince ourselves of an appropriate “punishment” for mismarked QB traffic, other than high packet loss in the case where QP is not implemented or potential for out-of-order delivery when QP is implemented.

Given this, using a WFQ-ish scheduler with a high NQB scheduler weight to achieve low latency is the wrong hammer to hit this nail, IMHO. A small queue by itself is insufficient to prevent capacity-seeking traffic from trying to grab that large & isolated share of capacity. If I were implementing this (and only this) I would consider putting NQB traffic in a bounded strict priority queue, feeding it priority credits at say 2-4% of link capacity. I would also put a policer in front of that queue set at a rate of 4-6% link capacity, with a large enough token bucket to let small NQB bursts through. That is a very simple implementation, available in lots of existing hardware, that achieves the stated objectives.

[GW] But priority isn’t necessary, and it results in the need for limitations on NQB bandwidth.  For example, in your implementation, what would happen when the arrival rate at the link is only 20% of link capacity but all of it is NQB?  I guess the policer would unnecessarily discard a large percentage of that traffic.

DoS-ing NQB traffic in this implemention is "easier" than DoS-ing it in your proposed scheduling approach, but a targeted NQB DoS attack will have less impact on capacity-seeking traffic, and DoS-ing residential access links using only best-effort service is already a thing, so I'm not sure it really matters.