Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04

"Black, David" <David.Black@dell.com> Tue, 08 May 2018 14:49 UTC

Return-Path: <David.Black@dell.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 20742124D37 for <tsvwg@ietfa.amsl.com>; Tue, 8 May 2018 07:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=l/lLvtmZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=wjWdzLNd
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 S0TKeo2Q3bMB for <tsvwg@ietfa.amsl.com>; Tue, 8 May 2018 07:49:21 -0700 (PDT)
Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 1B889124235 for <tsvwg@ietf.org>; Tue, 8 May 2018 07:49:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1525790960; x=1557326960; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=snB3tKRrOYWw05a8FwQ5Aw9Y1nF7udQ2SwP7uCEIiSA=; b=l/lLvtmZ2WNVWJ/1TlKA/2AW6k18qlQWytCWVzQeeATOUUSOQwx/4JYJ K26rlqLij12PlqTcFMh1YFAt90hJbnwEt5ShVXrjPYnZg44gteE4/CuDT X+kVtKHJ/p4EspqWc8fdihDOcD7IN7EGb90E/794IjE7m1XccwXMCs4nv M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F7AACWt/Fahz+a6ERcDgwBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGCbyl+DnooCphbgXmBD5M8gSk7CyMLhD4CgmYhNxUBAgEBAQEBAQI?= =?us-ascii?q?BAQIQAQEBCgsJCCgjDII1JAEOLxwhCAYBAQEBAQEnAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFwJDARICGAEBAQIBAToGHxoBBAcCAgIBCBEEAQELFAkHFhwUCQgBAQQOBQi?= =?us-ascii?q?DRQGBTggBDqlSgnaFTIJAAwUFhyR8gVU+gQ+CDH+DEQEBAQJbTwESASEFMYJ4g?= =?us-ascii?q?iSHFwiRDQMFAoVjbokvg2CHTYdBggWGXwIEAgQFAhSBJTKBBHFwgxOCLhppAQe?= =?us-ascii?q?CQ4UUhQQ6bwGPBYEfgRgBAQ?=
X-IPAS-Result: =?us-ascii?q?A2F7AACWt/Fahz+a6ERcDgwBAQEBAQIBAQEBCAEBAQGCbyl?= =?us-ascii?q?+DnooCphbgXmBD5M8gSk7CyMLhD4CgmYhNxUBAgEBAQEBAQIBAQIQAQEBCgsJC?= =?us-ascii?q?CgjDII1JAEOLxwhCAYBAQEBAQEnAQEBAQEBAQEBAQEBAQEBAQEBFwJDARICGAE?= =?us-ascii?q?BAQIBAToGHxoBBAcCAgIBCBEEAQELFAkHFhwUCQgBAQQOBQiDRQGBTggBDqlSg?= =?us-ascii?q?naFTIJAAwUFhyR8gVU+gQ+CDH+DEQEBAQJbTwESASEFMYJ4giSHFwiRDQMFAoV?= =?us-ascii?q?jbokvg2CHTYdBggWGXwIEAgQFAhSBJTKBBHFwgxOCLhppAQeCQ4UUhQQ6bwGPB?= =?us-ascii?q?YEfgRgBAQ?=
Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 09:49:18 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 20:49:01 +0600
Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w48EnAAv024353 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 May 2018 10:49:16 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w48EnAAv024353
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1525790956; bh=RMTDvhY4b+6/fpL2PhKEibA9+TY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=wjWdzLNd14XlQqO+iW2QKeiZKDSP9z+YdGUGO0yqhVDBCP5QvybqGg/hm72asNig6 bX4iP4haar99Sgkmbi0KstwTzjwop8+DU2q+OpAqD/61QVJGbWhh4Clo6lRjEqjuXO W7/EmfRXtyfUh2PTalADtI0rUnV8L5p0aYdV8DuE=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w48EnAAv024353
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 8 May 2018 10:48:46 -0400
Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w48EiJWc019802 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 8 May 2018 10:49:05 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0382.000; Tue, 8 May 2018 10:46:22 -0400
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "Bless, Roland (TM)" <roland.bless@kit.edu>
CC: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04
Thread-Index: AdPmoFK9aWKmiaf9TbeUMDqszKs2hwAL7mwAAAnbXQAAB3rSMA==
Date: Tue, 8 May 2018 14:46:22 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363010E8FF@MX307CL04.corp.emc.com>
References: <DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <ceeabcb5-a66b-8c31-f094-4c37d617acd8@kit.edu> <DB5PR0301MB190945262AFB792AA5A1CE629D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
In-Reply-To: <DB5PR0301MB190945262AFB792AA5A1CE629D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.33]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/g7-1AvatW9mpCq_0OiQ0Ak5fLVc>
Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 08 May 2018 14:49:24 -0000

Writing as an individual, not WG chair ...

> It provides a workaround for the IP precedence bleaching for LE traffic that
> you want to introduce - but what about all other PHBs?

The concern is not about what happens in Diffserv domains/regions that are updated to implement support for the new LE PHB, but what happens when that LE PHB traffic transits through routers elsewhere that bleach IP Precedence.

Right now IP Precedence bleaching tends to result in best effort service, which is ok, albeit not ideal.   If IP Precedence bleaching could result in a DSCP for the LE PHB, the result downstream of the bleaching could be worse than best effort service for a DSCP that was intended to obtain better than best effort service - that is the priority inversion that we're trying to avoid.

> Would they not require some intelligent rewrite of the DSCP when traffic
> enters the bleaching domain?

Unfortunately, that's wishful thinking, IMHO.  IP Precedence bleaching already violates a bunch of RFCs, dating back to RFC 2474.    We can write what we like in a new RFC, but that "running code" in deployed routers isn't going to magically stop bleaching IP Precedence just because we publish a new RFC.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander
> Vainshtein
> Sent: Tuesday, May 8, 2018 10:08 AM
> To: Bless, Roland (TM)
> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org
> Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-
> dscp-registry-04
> 
> Ronald,
> Lots of thanks for a prompt response.
> 
> I have to admit that your explanation looks problematic to me.
> It provides a workaround for the IP precedence bleaching for LE traffic that
> you want to introduce - but what about all other PHBs?
> Would they not require some intelligent rewrite of the DSCP when traffic
> enters the bleaching domain?
> And if so, why should not the same approach be used for LE in this domain?
> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
> 
> 
> -----Original Message-----
> From: Bless, Roland (TM) [mailto:roland.bless@kit.edu]
> Sent: Tuesday, May 8, 2018 12:26 PM
> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>;
> gorry@erg.abdn.ac.uk
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-
> dscp-registry-04
> 
> Hi Sasha,
> 
> Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein:
> > I have looked up the draft
> > <https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-04>,
> > and I have doubts regarding validity of its motivation.
> >
> > The draft says - correctly -that 22 out of 32 values in Pool 1 of the
> > DSCP code points have been already assigned, therefore it considers
> > this pool as nearly exhausted.
> >
> > What the draft does not say that, out of these 22 assignments, 2o have
> > been done in 1998 and one - in 1999. Only one assignment has been
> > requested in the past 19 years, and no assignments have been requested
> > after 2010.
> 
> > At this rate my estimate is that Pool 1 would suffice for the next 50+
> > years without its exhaustion becoming an issue. So why should the IETF
> > do anything */now/*?
> 
> This is motivated in section 1:
> 
>    The rationale for this update is a need
>    to assign codepoints for particular PHBs that are unable to use any
>    of the unassigned values in Pool 1.
> 
> This problem is caused by implementations that do IP precedence bleaching
> (i.e., zeroing the top three bits of the DSCP) thereby rewriting (or
> unintentionally mapping) DSCP values to other DSCP values. This is a problem
> for the mentioned LE PHB I-D https://tools.ietf.org/html/draft-ietf-tsvwg-le-
> phb
> It is possible that some other standardized DSCPs get mapped to the LE PHB
> DSCP if the LE DSCP were taken from the DSCP standards action pool 1
> (xxxxx0).
> 
> There are measurements and more background material for this:
> https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-
> 31measurements-concerning-the-dscp-for-a-le-phb-00
> https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf
> 
> Regards,
>  Roland
> 
> __________________________________________________________
> _________________
> 
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and then
> delete the original
> and all copies thereof.
> __________________________________________________________
> _________________