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

[Brian E Carpenter <[e-mail]>]

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.

    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
>>>
>>>
>>
>