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

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

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