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

[Gorry Fairhurst <[e-mail]>]

On 31/07/2017, 21:25, Brian E Carpenter wrote:
> On 01/08/2017 05:00, Fred Baker wrote:
>>
>>> On Jul 31, 2017, at 6:34 AM, [e-mail] wrote:
>>>
>>> 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.
>> https://tools.ietf.org/html/rfc2474#section-6 indicates that 000001 is experimental/local use, available for standards allocation only as necessary.
> "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..."
>
> That is a local use within a domain, completely compatible with both
> pools 2 and 3 which are both defined as for local use. So 000001
> is really not suitable for standards track recommendation, until
> pool 1 is full.
>
>> Pool 1 is 32 code points, of which I believe 20 are in use (figure 3 of RFC 4594). I'd rather not dip into pool 3 unnecessarily. Is there another option?
> 000010 is just fine. Why are we still discussing this?
>
>     Brian
The reason this is being discussed is that the primary objective of the 
LE PHB is to protect best-effort (BE) traffic (packets forwarded with 
the default PHB) from LE traffic in congestion situations, I think there 
is reasonable doubt that a LE service can be safely deployed across the 
Internet using a codepoint of 000010.

There seems evidence that there are still even now deployed routers that 
have not adjusted their remarking behaviour after the IETF deprecated 
ToS Precedence bleaching. I do think this change should have happened, 
and still think that routers still need to be updated. That does not 
however mean the IETF can simply ignore the consequences of this 
remarking still being deployed. A PS that advises LE traffic to be 
marked as 000010 and standardises LE treatment for 000010 needs to show 
that this is safe.

The key point is that introducing a LE service is not the same as 
introducing other treatments. A packet that uses AF marking and 
encounters ToS Precedence bleaching would expereince AF11, AF21, AF31, AF41
emerging remarked to a codepoint of 000010, and AF12, AF22, AF32, AF42, 
VA would emerge as 000100, etc.

Because the LE PHB is a lower effort PHB, implementing a PHB with a 
codepoint of 000010 would result in some traffic originally marked as 
AFx1 being assigned a lower effort than AFx1 or AFx2. That in itself 
would be less of an issue - since remarking happens - but here there  is 
a risk that traffic trying to utilise the AF PHB groups - e.g., where 
AF41 can become carried using the LE PHB while traffic originally marked 
AF42 would be carried using the default PHB.  This priority inversion 
seems very undesirable.

If we need to seek a different codepoint, I think this could be pursued 
with IANA. You are correct in that the DSCPs in the IANA pool 3 "May be 
utilized for future Standards Action allocations as necessary".  The 
policy is actually stated for pool 3 in the registry is "should be 
preferentially utilized for standardized assignments if Pool 1 is ever 
exhausted" and that this pool should only be used when needed. There are 
presently 23/32 allocations. As the TSVWG Chairs indicated, they would 
be willing to consider making the changes needed to allow IANA to make a 
pool 3 allocation for the LE service, if none of the remaining 
codepoints in pool 1 can be safely utilised.

Gorry