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

[<[e-mail]>]

Brian, David, 

to complete RFC4594 discussion, it also says:

"In network segments that use IP precedence marking, only one of
the two service classes can be supported, High-Throughput Data or
Low-Priority Data.  We RECOMMEND that the DSCP value(s) of the
unsupported service class be changed to 000xx1 on ingress and
changed back to original value(s) on egress of the network segment
that uses precedence marking.  For example, if Low-Priority Data
is mapped to Standard service class, then 000001 DSCP marking MAY
be used to distinguish it from Standard marked packets on egress."

DSCP 000001 might be an option. No other IETF recommended DSCP is re-marked to this one. It is to some extent RFC4594 compatible and RFC8100 could cope with it if default transport is applied. 

I can't offer you measurement data.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[e-mail]] Im Auftrag von Brian E Carpenter
Gesendet: Sonntag, 16. Juli 2017 22:46
An: Black, David <[e-mail]>; [e-mail]
Cc: Roland Bless <[e-mail]>; [e-mail]
Betreff: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

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