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

[Gorry Fairhurst <[e-mail]>]

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