[tsvwg] NQB draft - comments from David B

"Black, David" <David.Black@dell.com> Sun, 15 September 2019 23:13 UTC

Return-Path: <David.Black@dell.com>
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 E41BB1200F7 for <tsvwg@ietfa.amsl.com>; Sun, 15 Sep 2019 16:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.19
X-Spam-Status: No, score=-0.19 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_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=2.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=YUGz45Zo; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=YcT1Sw3k
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hJ2MxDfM7DwY for <tsvwg@ietfa.amsl.com>; Sun, 15 Sep 2019 16:13:52 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com []) (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 88D9212006E for <tsvwg@ietf.org>; Sun, 15 Sep 2019 16:13:52 -0700 (PDT)
Received: from pps.filterd (m0170397.ppops.net []) by mx0b-00154904.pphosted.com ( with SMTP id x8FN9gqK018752 for <tsvwg@ietf.org>; Sun, 15 Sep 2019 19:13:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=cpd9SUmYf39oknRHT3xuVIjNuSDLk+50vpA5mZ1h+eA=; b=YUGz45Zo2eVN9wjEFGwGtJQA2sq6rwC0pea6vXTKzZM7dHreO8i57pgllIwt/vlRSCZO 1FrgGL/KR5jMQ81cYUzMc8eTrKOE8blhyK+lIRTUamhCUFGtWcPhvCpXd9xLfki6w8UN Kkr6Gxd/jBGeYScUUISFpVa++2CWTetM5AsRr5q8aEs/bxzyIo5d+ao/TyGX5ZeFra21 QmEdFwBIiyJMw5/eM4guYP3k3Lw1/gtr5hanGsYKUybFaeNgKvTaXGDT7eEmsSAo3zWp oWH+WGjzjBWTi2PGf/RED5msiB1DZXL3Ygg1Kq9/4Yq2PkayIIJteBiS0KQVVG6bFxCb YQ==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com []) by mx0b-00154904.pphosted.com with ESMTP id 2v0s9tn8v9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 19:13:51 -0400
Received: from pps.filterd (m0134746.ppops.net []) by mx0a-00154901.pphosted.com ( with SMTP id x8FND1Ur078378 for <tsvwg@ietf.org>; Sun, 15 Sep 2019 19:13:50 -0400
Received: from mailuogwhop.emc.com (mailuogwhop-nat.lss.emc.com [] (may be forged)) by mx0a-00154901.pphosted.com with ESMTP id 2v1dd1fr17-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 19:13:49 -0400
Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com []) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8FNDjUS010138 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 19:13:47 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x8FNDjUS010138
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1568589228; bh=m9c4oRwD462d7O8xoQ+/LQBhQks=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=YcT1Sw3kbL5OldH+OdnYDwqVe3g5BEVpxx4M/uHB8OgOOyoLTkl0vxYeWgW2QGYBU YrUTI+u7+5Z0F+gbFg9o9nRoVlcAIEPRXwT0ZMTWajgRSzozdZp8cFTnHx49xJqkke TtgIiNNRZqoiQeU2wro3thSBe/uGisDaYzwWiI6c=
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com []) by maildlpprd05.lss.emc.com (RSA Interceptor) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 19:12:44 -0400
Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com []) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8FNBFCZ018271 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for <tsvwg@ietf.org>; Sun, 15 Sep 2019 19:12:48 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([]) with mapi id 14.03.0439.000; Sun, 15 Sep 2019 19:11:43 -0400
From: "Black, David" <David.Black@dell.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: NQB draft - comments from David B
Thread-Index: AdVsGmpmB934Nw3OTM2AzPH09kVyZg==
Date: Sun, 15 Sep 2019 23:11:42 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936306F8E18@MX307CL04.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-09-15T22:38:08.4347275Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936306F8E18MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-15_12:2019-09-11,2019-09-15 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 spamscore=0 malwarescore=0 adultscore=0 priorityscore=1501 phishscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909150254
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 adultscore=0 spamscore=0 impostorscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909150254
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/QEmv9grs174IBNNPbOXCvirkfQA>
Subject: [tsvwg] NQB draft - comments from David B
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: Sun, 15 Sep 2019 23:13:54 -0000

Some short comments on a few topics as an individual - all of these are IMHO.  Sorry for the delayed silence - I got laid out for several days by a kidney stone starting on Sep 4, and catching up has taken a while.

-- [1] Traffic Protection (e.g., Queue Protection) and the NQB PHB.

If Traffic Protection/Queue Protection is completely optional for the NQB PHB, would someone please explain how this PHB differs from EF and VOICE-ADMIT?  In particular (at the least as a straw proposition for demolition purposes) - Should the NQB draft be re-focused on why non-queue-building flows are good fits to those PHBs and how to effectively use traffic protection (e.g., queue protection) with those PHBs??

FWIW, my take on the discussion so far is that the "no incentives to misuse" claim lacks credibility, making "MUST implement traffic protection" an appropriate place to start from to proceed to specify exceptions.  The walled-garden/app-store example might be one such exception, although that appears to assume perfect curation of the app store, a proposition for which there are plenty of counterexamples.

-- [2] Priority Queuing or the lack thereof.

If NQB PHB traffic is never supposed to be subject to priority queuing, then 0x2A sure looks like the wrong default DSCP to recommend (IMHO).

-- [3] RFC 2119 hair-splitting.

> To prove MUST is necessary, you have to prove protection is necessary in every scenario.

That's definitely wrong for "MUST implement" and likely wrong for "MUST use."   The "MUST implement" view is not just my opinion - this is how the Security Area views implementation requirements for security mechanisms - "MUST implement" ensures that the mechanisms are available if the operator should discover that she needs them.  As we appear to be dealing with potential for  theft and denial of service attacks, we should expect to have to answer to the Security Area on this topic.

With regards to "in every scenario," I would suggest listing the interesting/important scenarios that are exceptions to "MUST implement" with cogent explanations of why they are exceptions.

Thanks, --David
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754