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

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 07 Jul 2017 09:58:01 +0100

This email is intended to start a discussion about the most appropriate 
DiffServ codepoint to assign to the LE PHB specified in:
https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02

The current list of available codepoints is listed by IANA here:
https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml

The draft currently suggests using the DSCP value 3, '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)

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 07 Jul 2017 10:36:31 +0100

Things to consider:

     Things to consider:

Gorry Fairhurst
(TSVWG Co-Chair)

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Fri, 7 Jul 2017 13:03:40 +0200

Hi Gorry,

> The draft currently suggests using the DSCP value 3, '000010'.

I think it is DSCP value 2.

> applications) that may get in the way of the deployment of the LE PHB?

Currently, nothing should be using a non-assigned Standard DSCP.
I really don't like these discussion along the lines of: oh, probably
there are some standard-ignoring boxes/apps out there, so lets try to
work around their broken design. So, yes, it's probably good to know,
but IMHO it's better to get this other stuff fixed rather than to always
create workaround.

>     - Is this codepoint observed in the wild due to common DSCP-mangling
> pathologies (such as ToS-byte bleaching)?
> 

> consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'.

I don't see any compelling reason to start using another pool right now.

> suggesting a more appropriate codepoint for the working group to request.

Thanks for triggering the discussion.

Regards,
 Roland

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 07 Jul 2017 12:23:59 +0100

On 07/07/2017, 12:03, Bless, Roland (TM) wrote:
>> The draft currently suggests using the DSCP value, '000010'.
That's two indeed:-).
> but IMHO it's better to get this other stuff fixed rather than to always
And, I think a more usedful disucssion here is around - "what happens 
when you use existing codepoints that are IETF-approved, and they pass 
through the current Internet" - do they emerge as the codepoint you propose?

> I don't see any compelling reason to start using another pool right now.
Don't you? I think this depends on the outcome.
> Thanks for triggering the discussion.
Roland, do you have any measurement data?

Gorry

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Jul 2017 08:50:03 +1200

> through the current Internet" - do they emerge as the codepoint you propose?

Since the architecture allows *any* rewriting whatever of the DSCP value
at a domain boundary, I'm not clear why any of this is relevant. The Internet
isn't supposed to be transparent to DSCP values, and all DSCP values are
recommendations anyway. 

It seems to me that RFC8100 resolves the issue about what is expected to
work across domain boundaries; all we are doing here is fixing the historical
misuse of a codepoint.

So 000010 seems like a perfectly fine bit pattern to me.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Sun, 9 Jul 2017 11:12:26 +0000

> On 7 Jul 2017, at 21:50, Brian E Carpenter <[email-masked]> wrote:
> 

Do you mean DSCP 8 being used by LBE/Scavenger as far back as 2002 or so?

> So 000010 seems like a perfectly fine bit pattern to me.

Indeed. It’s good to have some default value that can be agreed between domains.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Jul 2017 08:29:41 +1200

> Do you mean DSCP 8 being used by LBE/Scavenger as far back as 2002 or so?

Yes. IMHO we made a mistake when the use of CS1 for LE was first documented
(draft-bless-diffserv-pdb-le-00 in June 2002, and I was even a co-author
on that version). We should have said that it was a Bad Idea; instead we
said it was "justified" to violate a SHOULD in RFC2474.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Sun, 9 Jul 2017 21:02:21 +0000

> On 9 Jul 2017, at 21:29, Brian E Carpenter <[email-masked]> wrote:
> 

A bit moot now, but it would be interesting to know where the choice of DSCP 8 for LBE first originated - I guess from the QBSS work, but we copied it in the interests of interoperability across the NRENs in our TF-NGN experiments in early 2002.

Here’s a slide deck from Stanislav in 2001 - https://www.internet2.edu/presentations/CampusWorkshopAtlanta/Shalunov-QoS-Atlanta.pdf - but no mention of the CS1 conflict, or the reason to pick the value, just that 001000 was a “special global value”.  

Tim

---

From: Roland Bless <[email-masked]>
Date: Sun, 9 Jul 2017 23:52:53 +0200

Hi Tim,

> A bit moot now, but it would be interesting to know where the choice of DSCP 8 for LBE first originated - I guess from the QBSS work, but we copied it in the interests of interoperability across th…

It think the CS1 proposal came in via this draft here:
https://tools.ietf.org/html/draft-ietf-diffserv-pdb-bh-00
I raised my concerns here:
https://www.ietf.org/mail-archive/web/diffserv/current/msg02013.html
Brian's reply was here:
https://www.ietf.org/mail-archive/web/diffserv/current/msg02014.html
So basically the IEEE 802.1q used PCP1 as Background class
and the idea was probably to do it similarly with the CS codepoints.

> Here’s a slide deck from Stanislav in 2001 - https://www.internet2.edu/presentations/CampusWorkshopAtlanta/Shalunov-QoS-Atlanta.pdf - but no mention of the CS1 conflict, or the reason to pick the v…

Our first proposal (preceding QBSS)
https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00
used an experimental codepoint.

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Jul 2017 11:19:42 +1200

> https://www.ietf.org/mail-archive/web/diffserv/current/msg02014.html

Yes. It was a judgment call, but I now think it was wrong.

   Brian

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 10 Jul 2017 09:00:02 +0100

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

   Things to consider:

     Things to consider:

Gorry Fairhurst
(TSVWG Co-Chair)

When

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 10 Jul 2017 18:11:45 +0200

Hi Gorry,

> Roland, do you have any measurement data?

Unfortunately not.

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jul 2017 08:36:08 +1200

> 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

---

From: "Black, David" <[email-masked]>
Date: Sun, 16 Jul 2017 10:18:11 +0000

Two comments with WG chair hat OFF:

[1] As an author of RFC 8100 -

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

[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).

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Monday, July 10, 2017 4:36 PM
> To: [email-masked]
> Cc: Roland Bless <[email-masked]>; [email-masked]
> Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for
> LE PHB?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Jul 2017 08:46:09 +1200

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

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

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

    Brian

---

From: <[email-masked]>
Date: Mon, 31 Jul 2017 13:34:54 +0000

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:[email-masked]] Im Auftrag von Brian E Carpenter
Gesendet: Sonntag, 16. Juli 2017 22:46
An: Black, David <[email-masked]>; [email-masked]
Cc: Roland Bless <[email-masked]>; [email-masked]
Betreff: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

On 16/07/2017 22:18, Black, David wrote:
>> "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.
> 

    Brian

>> Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use 
>> for LE PHB?
>>
>> *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
>>
>>> 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".
>>>
>>> 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.
>>>
>>> deprecated!) However, that's not the point, if this remarking is 
>>> still out there, then we can reaonably expect some packets to be remarked.
>>> 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
>>>
>>> ----
>>>
>>>      - Is there ant evidence that this DSCP value is less likely to 
>>> be forwarded than other unused codepoints?
>>> 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
>>>
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 31 Jul 2017 10:00:42 -0700

> On Jul 31, 2017, at 6:34 AM, [email-masked] wrote:
> 

https://tools.ietf.org/html/rfc2474#section-6 indicates that 000001 is experimental/local use, available for standards allocation only as necessary. 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?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Aug 2017 08:25:37 +1200

On 01/08/2017 05:00, Fred Baker wrote:
> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 01 Aug 2017 07:53:35 +0100

> 000010 is just fine. Why are we still discussing this?
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