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

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

On 16/07/2017 22:18, Black, David wrote:
> Two comments with WG chair hat OFF:
> 
> [1] As an author of RFC 8100 -
> 
>> "We agree to follow RFC8100" might be a minimal SLA. But
>> absent that, there is very little we can say. I'm not aware
>> of any measurement data that would help, unfortunately.
> 
> Adding an LE traffic class to RFC 8100 came up during discussion of RFC 8100 (it was referred to as "scavenger" in that discussion), and was deferred, e.g., due to this DSCP codepoint concern.   In principle, LE could be added to RFC 8100, but I caution that the underlying MPLS TC (Traffic Class - see RFC 5462) codepoint space is a *very* limited resource.  TC is a 3-bit field, and so adding another traffic class to RFC 8100 would recommend use of the 5th value on at least interconnects - doing this requires careful consideration, including by network operators.

Understood. So the choice there for LE will be between remarking as BE or dropping, as discussed in the parallel thread.

> [2] As  an individual: Also, while RFC 3662 suggested possible use of CS1, in practice, that use of CS1 for LE (Low Priority Data Traffic) was codified by RFC 4594 (e.g., see Section 4.10), even though RFC 4594 is an Informational RFC (RFC 4594 is widely used).

Indeed. Hence the "Updates: 4594 (if approved)".

    Brian

> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: tsvwg [mailto:[e-mail]] On Behalf Of Brian E Carpenter
>> Sent: Monday, July 10, 2017 4:36 PM
>> To: [e-mail]
>> Cc: Roland Bless <[e-mail]>; [e-mail]
>> Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for
>> LE PHB?
>>
>>> makring interdomain diffserv support unpredictable.
>>
>> That is the whole point, really. Interdomain diffserv support
>> *is* unpredictable, more or less by definition, unless there
>> is an SLA in place between the domains that defines what happens
>> to packets with specific markings as they cross the border.
>>
>> "We agree to follow RFC8100" might be a minimal SLA. But
>> absent that, there is very little we can say. I'm not aware
>> of any measurement data that would help, unfortunately.
>>
>> Regards
>>    Brian
>>
>> On 10/07/2017 20:00, Gorry Fairhurst wrote:
>>> When I asked the questions below, I didn't really have in mind a beauty
>>> contest, or to identify squating on IANA-allocated DSCP values by
>>> others. My concern was more about widely deploying a class that had
>>> lower effort, and the implications on being able to work interdomain
>>> with traffic not intended not to be "LE".
>>>
>>> At the moment, any remarking is likely to reduce the class by which
>>> traffic is identified, e.g., a network router on path bleaching the DSCP
>>> to zero would result in the packet receiving the default PHB treatment
>>> for the remainder of its path. This maybe wasn't intended, but to me
>>> it's quite OK. If two packets were marked with relative priority
>>> (AF21,AF22) etc, it seems likely that both will be remarked to zero, or
>>> that the relative priority is preseverved.
>>>
>>> When we introduce a LE PHB, then any traffic that finally results in the
>>> new LE class will receive less than default treatment (we hope!) My
>>> concern is whether there are widely deployed pathologies (especially in
>>> old equipment) that would result in some codepoints being remarked to
>>> the default PHB, while other codepoints get remarked to a LE PHB. This
>>> could easily "invert" the relative priority expected by an application,
>>> in ways we warned about in the DART work, makring interdomain diffserv
>>> support unpredictable.
>>>
>>> In practice, I have seen there are many pathologies that deployed
>>> equipment exhibits - I spoke about some of this in maprg last IETF -
>>> e.g., some nodes still implement ToS semantic processing. (This is
>>> deprecated!) However, that's not the point, if this remarking is still
>>> out there, then we can reaonably expect some packets to be remarked.
>>> This seems particularly ugly when we introduce use of a LE codepoint
>>> that will actually From what I talked about in maprg, I have a fear that
>>> this case could be rather common if we do not take care in selection of
>>> the codepoint. I think the WG can data to talk about this.
>>>
>>> Gorry
>>>
>>> ----
>>>
>>> The draft currently suggests using the DSCP value 2, '000010'.
>>>
>>> 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?
>>>      - 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'.
>>>
>>> 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.
>>>
>>> Gorry Fairhurst
>>> (TSVWG Co-Chair)
>>>
>>> When
>>>
>