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

"Bless, Roland (TM)" <roland.bless@kit.edu> Tue, 08 May 2018 09:25 UTC

Return-Path: <roland.bless@kit.edu>
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 F417E127876 for <tsvwg@ietfa.amsl.com>; Tue, 8 May 2018 02:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 vLDMcelHJfhb for <tsvwg@ietfa.amsl.com>; Tue, 8 May 2018 02:25:43 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 6A0981275FD for <tsvwg@ietf.org>; Tue, 8 May 2018 02:25:43 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1fFysK-0005oG-Kv; Tue, 08 May 2018 11:25:36 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 8EFE8420F55; Tue, 8 May 2018 11:25:36 +0200 (CEST)
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <ceeabcb5-a66b-8c31-f094-4c37d617acd8@kit.edu>
Date: Tue, 08 May 2018 11:25:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1525771536.722003011
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bpMlPpbjpFp52dTgTyjwkKZj7yE>
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 09:25:46 -0000

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