Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

[Tim Chown <[e-mail]>]

> On 9 Jul 2017, at 21:29, Brian E Carpenter <[e-mail]> wrote:
> 
> On 09/07/2017 23:12, Tim Chown wrote:
>>> On 7 Jul 2017, at 21:50, Brian E Carpenter <[e-mail]> wrote:
>>> 
>>> On 07/07/2017 23:23, Gorry Fairhurst wrote:
>>>> On 07/07/2017, 12:03, Bless, Roland (TM) wrote:
>>>>> Hi Gorry,
>>>>> 
>>>>> Am 07.07.2017 um 10:58 schrieb Gorry Fairhurst:
>>>>>> This email is intended to start a discussion about the most appropriate
>>>>>> DiffServ codepoint to assign to the LE PHB specified in:
>>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02
>>>>>> 
>>>>>> The current list of available codepoints is listed by IANA here:
>>>>>> https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml
>>>>>> 
>>>>>> The draft currently suggests using the DSCP value, '000010'.
>>>>> I think it is DSCP value 2.
>>> 
>>>> That's two indeed:-).
>>> 
>>>>>> Question 1: Is this codepoint a good choice for the TSVWG group to
>>>>>> assign for the LE PHB?
>>>>>> 
>>>>>>  Things to consider:
>>>>>>    - Is the codepoint currently being used for other (non-standard
>>>>>> applications) that may get in the way of the deployment of the LE PHB?
>>>>> Currently, nothing should be using a non-assigned Standard DSCP.
>>>>> I really don't like these discussion along the lines of: oh, probably
>>>>> there are some standard-ignoring boxes/apps out there, so lets try to
>>>>> work around their broken design. So, yes, it's probably good to know,
>>>>> but IMHO it's better to get this other stuff fixed rather than to always
>>>>> create workaround.
>>> 
>>>> And, I think a more usedful disucssion here is around - "what happens 
>>>> when you use existing codepoints that are IETF-approved, and they pass 
>>>> through the current Internet" - do they emerge as the codepoint you propose?
>>> 
>>> Since the architecture allows *any* rewriting whatever of the DSCP value
>>> at a domain boundary, I'm not clear why any of this is relevant. The Internet
>>> isn't supposed to be transparent to DSCP values, and all DSCP values are
>>> recommendations anyway. 
>>> 
>>> It seems to me that RFC8100 resolves the issue about what is expected to
>>> work across domain boundaries; all we are doing here is fixing the historical
>>> misuse of a codepoint.
>> 
>> Do you mean DSCP 8 being used by LBE/Scavenger as far back as 2002 or so?
> 
> Yes. IMHO we made a mistake when the use of CS1 for LE was first documented
> (draft-bless-diffserv-pdb-le-00 in June 2002, and I was even a co-author
> on that version). We should have said that it was a Bad Idea; instead we
> said it was "justified" to violate a SHOULD in RFC2474.

A bit moot now, but it would be interesting to know where the choice of DSCP 8 for LBE first originated - I guess from the QBSS work, but we copied it in the interests of interoperability across the NRENs in our TF-NGN experiments in early 2002.

Here’s a slide deck from Stanislav in 2001 - https://www.internet2.edu/presentations/CampusWorkshopAtlanta/Shalunov-QoS-Atlanta.pdf - but no mention of the CS1 conflict, or the reason to pick the value, just that 001000 was a “special global value”.  

Tim

>    Brian
> 
>>> So 000010 seems like a perfectly fine bit pattern to me.
>> 
>> Indeed. It’s good to have some default value that can be agreed between domains.
>> 
>> Tim
>> 
>>>   Brian
>>> 
>>>>>>    - Is there ant evidence that this DSCP value is less likely to be
>>>>>> forwarded than other unused codepoints?
>>>>>>    - Is this codepoint observed in the wild due to common DSCP-mangling
>>>>>> pathologies (such as ToS-byte bleaching)?
>>>>>> 
>>>>>> Question 2: Is there an alternate unassigned codepint that could be
>>>>>> chosen that would give better opprotunities for deployment?
>>>>>>    Things to consider:
>>>>>>    - A codepoint less than 7 appears to have less chance of
>>>>>> DSCP-mangling pathologies (such as ToS-byte bleaching)
>>>>>>    - IANA currently allocates from pool 1 (xxxxx0), but we could
>>>>>> consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'.
>>>>> I don't see any compelling reason to start using another pool right now.
>>> 
>>>> Don't you? I think this depends on the outcome.
>>> 
>>>>>> Measurement experience and thoughts on this topic are welcome on the
>>>>>> mailing list ahead of the TSVWG meeting. At this meeting, I would like
>>>>>> to see some discussion confirming the choice of DSCP codepoint or
>>>>>> suggesting a more appropriate codepoint for the working group to request.
>>>>> Thanks for triggering the discussion.
>>>>> 
>>>>> Regards,
>>>>> Roland
>>>> Roland, do you have any measurement data?
>>>> 
>>>> Gorry
>>>> 
>>>> 
>>> 
>> 
>