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

[Gorry Fairhurst <[e-mail]>]

Hi,

Maybe I can provide a little more context about other unallocated values in the registry. Each request for a new DSCP needs to be considered carefully and separately looking at the implications on both the deployed use of Codepoints and the needs for the PHB. As it happens, the unassigned DSCPs in pool 1 could well remain useful for any new PHBs- if any new ones are approved by TSVWG  that can be bleached to default (BE) - the case for most currently defined PHBs. 

I expect the  new pool will be only used by IANA requests from TSVWG when there is a case for not using any of the remaining pool 1 values. That case has been made for the LE PHB.  There could potentially be other allocations in the future, but that is none are currently considered.

Gorry

Sent from my iPad

> On 8 May 2018, at 15:55, Alexander Vainshtein <[e-mail]> wrote:
> 
> David,
> Lots of thanks for a very detailed explanation.
> 
> Coming back to my original doubt, , changing the IANA allocation policy on Pool 3 (16 values) in order to make just one value standard still looks an exaggeration to me. 
> What are we going to do with the remaining 15 values? 
> 
> Regards,
> Sasha
> 
> Office: [phone]
> Cell:      [phone]
> Email:   [e-mail]
> 
> 
> -----Original Message-----
> From: Black, David [mailto:[e-mail]] 
> Sent: Tuesday, May 8, 2018 5:46 PM
> To: Alexander Vainshtein <[e-mail]>; Bless, Roland (TM) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: RE: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04
> 
> 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:[e-mail]] On Behalf Of Alexander 
>> Vainshtein
>> Sent: Tuesday, May 8, 2018 10:08 AM
>> To: Bless, Roland (TM)
>> Cc: [e-mail]; [e-mail]
>> 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: [phone]
>> Cell:      [phone]
>> Email:   [e-mail]
>> 
>> 
>> -----Original Message-----
>> From: Bless, Roland (TM) [mailto:[e-mail]]
>> Sent: Tuesday, May 8, 2018 12:26 PM
>> To: Alexander Vainshtein <[e-mail]>;
>> [e-mail]
>> Cc: [e-mail]
>> 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-sess
>> b-
>> 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.
>> __________________________________________________________
>> _________________
> 
> ___________________________________________________________________________
> 
> 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.
> ___________________________________________________________________________