Subject: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Jul 2013 16:35:47 -0700

The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it was an individual draft then WG draft in another WG and I don't think there is much more to say about it. This is one of the normative dependencies of the webrtc work and that stuff is already getting implemented in browsers so I want to move this along in an expedient fashion. 

I think it is ready for WGLC. If there are any issues people think need to be discussed before WGLC, please let us know so we can resolve them in Berlin.

Thanks, Cullen

---

From: Dave Taht <[email-masked]>
Date: Mon, 8 Jul 2013 17:00:33 -0700

> I think it is ready for WGLC. If there are any issues people think need to be discussed before WGLC, please let us know so we can resolve them in Berlin.

Note: The sample code in the document does not include correct code
for ipv6, which is more or less:

IPv6 DiffServ

IPv4   IPPROTO_IP     IP_TOS
IPv6   IPPROTO_IPV6   IPV6_TCLASS

So, to set the DSCP in IPv6 you must use IPv6 Traffic Class field.

int ds = IPTOS_DSCP_AF11;
int rc = setsockopt(fd, IPPROTO_IPV6, IPV6_TCLASS, &ds, sizeof(ds));

see:

http://www.bufferbloat.net/issues/249

for more details

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Jul 2013 17:28:21 -0700

Good catch - thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jul 2013 10:50:55 +0300

Hi Cullen, 

this document is still an individual draft and so I am not sure what you mean by working group last call. 

- From a content point of view I am not sure how useful it is. I shared my views about how this applies to LTE; IMHO it is not applicable.

It would be so great if we could solve all QoS challenges by defining yet another set of DiffServ code points. 

Ciao
Hannes

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 09 Jul 2013 09:03:31 +0100

> I think it is ready for WGLC. If there are any issues people think need to be discussed before WGLC, please let us know so we can resolve them in Berlin.

In the email above you ask for WGLC. The first step is for the group to 
consider adoption. As I recall, this draft was brought to TSVWG for 
consideration because it discusses transport mappings to QoS.

I understand from the draft this proposes default mappings for an 
RTCWeb use cases. As I see it, the present draft:

* Advocates use of separate QoS code points for different streaming 
components

* Describes both endpoint handling of priority for the media and 
transport priority/precedence (aka DSCP).

* Proposes formalising a mapping between specific DSCPs and subnetwork 
QoS functions (LTE, WiFi - but not general Ethernet).

Please read this draft and comment on the list - we will table this for 
discussion at the next IETF meeting.

Gorry

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 9 Jul 2013 19:48:17 +1000

So, there is a significant bug in the mappings proposed.  That is this:
there is a substantial deployed base of home routers and other network
devices that use the Linux kernel's default output queue pfifo_fast, which
uses a mapping derived from RFC 1349 (documented in the linux man page
tc_prio, see for example http://linux.die.net/man/8/tc-prio)   If the
proposed mappings don't work with that queue discipline, they won't work on
the deployed base.  pfifo_fast has then unfortunate properties of ignoring
the top 3 bits of the tos byte, and sometimes paying attention to one of
the ECN bits in choosing a queueing band.

In effect, since Linux has produced a de-facto standard codepoint
assignment for the edge of the network, we had better recommend something
compatible.  The proposed mapping uses EF for all audio, which will create
a priority inversion and have all the Linux devices on the edge classify
that traffic as 'bulk interactive', lower than the interactive video at
AF4x in the 'interactive' band.  This is probably not what we want.

I've filled out the linux band numbers in table 1 from the draft; the third
number in each table cell is the linux band, smaller number is higher
priority:
+-----------------------+-------------+-------------+-------------+
| Media Type            |    Low      |   Medium    |    High     |
+-----------------------+-------------+-------------+-------------+
| Audio                 |  46 (EF)  1 |  46 (EF)  1 |  46 (EF)  1 |
| Interactive Video     | 38 (AF43) 1 | 36 (AF42) 0 | 34 (AF41) 2 |
| Non-Interactive Video | 26 (AF33) 1 | 28 (AF32) 0 | 30 (AF31) 2 |
| Data                  |  8 (CS1)  1 |   0 (BE)  1 | 10 (AF11) 2 |
+-----------------------+-------------+-------------+-------------+
      Table 1 - Media Type, Priority, and DSCP Mapping

As can readily be seen, there are a number of priority inversions there.
 Effectively, RFC 4594 doesn't work as designed at the edge of the network,
and we have to go back to RFC 1349, or at least a restricted set of RFC
4594 codepoints.

Effectively, Linux has given us a priority series that reads:
AFx2>AFx3>AFx1>(CS1 or BE)

So, for the purpose of working with both Linux routers and RFC 4594, the
useful series of codepoints are AF42>AF33>AF21>(CS1 or BE), and it becomes
an exercise of deciding where to place those codepoints in the table.  I'd
rather use CS1 than BE because it at least states that the application is
doing QoS marking.

Aside from fixing the actual mappings, though, the draft is a great idea
and really should be published as soon as reasonably possible.

On Tue, Jul 9, 2013 at 6:03 PM, Gorry Fairhurst <[email-masked]>wrote:

>> The draft-dhesikan-tsvwg-rtcweb-**qos draft was discussed extensively
>> when it was an individual draft then WG draft in another WG and I don't
>> think there is much more to say about it. This is one of the normative
>> dependencies of the webrtc work and that stuff is already getting
>> implemented in browsers so I want to move this along in an expedient
>> fashion.
>>
>> I think it is ready for WGLC. If there are any issues people think need
>> to be discussed before WGLC, please let us know so we can resolve them in
>> Berlin.
>>
>> Thanks, Cullen
>>
>>
> I understand from the draft this proposes default mappings for an RTCWeb
> use cases. As I see it, the present draft:
>
> * Describes both endpoint handling of priority for the media and transport
> priority/precedence (aka DSCP).
>
> * Proposes formalising a mapping between specific DSCPs and subnetwork QoS
> functions (LTE, WiFi - but not general Ethernet).
>

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 09 Jul 2013 22:56:36 -0400

> The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it was an individual draft then WG draft in another WG and I don't think there is much more to say about it. This is one of…

Without checking ... it makes no sense to me that there would be
a normative dependency on this since it does not impact the
interoperability or correctness of an implementation.

It's purely a performance enhancement, if/when it actually causes
the intended things to happen in the network.

That said, I think the interesting facet of this document is that
packets within the same flow (defined by 5-tuple of address-port
pairs and protocol number) are receiving different codepoints, and
the implications of that for a CC that may be on top of them need
to be delved into.  There isn't really text or recommendations
going into that, which seems to be the important part, as if you
can figure that out, these mappings are the more obvious part.

So, I think it might make sense to do this, but the current
document isn't addressing the implications or how this works in
a bigger system sense, and I don't think the particular marking
tables are the hard or important part.

-- 
Wes Eddy
MTI Systems

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Sun, 14 Jul 2013 18:46:28 +0000

Andrew,

Thank you for reviewing the draft and pointing out the issue that will arise with the deployed base.

Just so I am clear, you are proposing a couple of hardships with the current draft:

1.       Smaller set of values that will work with the below-mentioned implementations

2.       The ordering be different in terms of priority from what is proposed not only in this draft but the work prior that my draft is leveraging. For example AF2 > AF3 and at the same time > AF1.

Defining a smaller set of values may be alright except we lose the granularity and then having a mechanism to restore the real value in the network becomes important. My draft alludes to such a service which will take policy into account and impact markings if needed. If we restrict the values to a very small set, such a service will become critical.

The other challenge I see is with the relative position of the values being different from what is traditionally known for DSCP where EF> AF4x >AF3x>... How have you handled it so far in a non-web rtc environment?

If I have not understood your comments properly, please correct.

Regards,
Subha

.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew McGregor
Sent: Tuesday, July 09, 2013 2:48 AM
To: [email-masked]
Cc: tsvwg
Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

So, there is a significant bug in the mappings proposed.  That is this: there is a substantial deployed base of home routers and other network devices that use the Linux kernel's default output queue pfifo_fast, which uses a mapping derived from RFC 1349 (documented in the linux man page tc_prio, see for example http://linux.die.net/man/8/tc-prio)   If the proposed mappings don't work with that queue discipline, they won't work on the deployed base.  pfifo_fast has then unfortunate properties of ignoring the top 3 bits of the tos byte, and sometimes paying attention to one of the ECN bits in choosing a queueing band.

In effect, since Linux has produced a de-facto standard codepoint assignment for the edge of the network, we had better recommend something compatible.  The proposed mapping uses EF for all audio, which will create a priority inversion and have all the Linux devices on the edge classify that traffic as 'bulk interactive', lower than the interactive video at AF4x in the 'interactive' band.  This is probably not what we want.

I've filled out the linux band numbers in table 1 from the draft; the third number in each table cell is the linux band, smaller number is higher priority:

As can readily be seen, there are a number of priority inversions there.  Effectively, RFC 4594 doesn't work as designed at the edge of the network, and we have to go back to RFC 1349, or at least a restricted set of RFC 4594 codepoints.

Effectively, Linux has given us a priority series that reads: AFx2>AFx3>AFx1>(CS1 or BE)

So, for the purpose of working with both Linux routers and RFC 4594, the useful series of codepoints are AF42>AF33>AF21>(CS1 or BE), and it becomes an exercise of deciding where to place those codepoints in the table.  I'd rather use CS1 than BE because it at least states that the application is doing QoS marking.

Aside from fixing the actual mappings, though, the draft is a great idea and really should be published as soon as reasonably possible.

On Tue, Jul 9, 2013 at 6:03 PM, Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:
On 09/07/2013 00:35, Cullen Jennings wrote:

Thanks, Cullen

In the email above you ask for WGLC. The first step is for the group to consider adoption. As I recall, this draft was brought to TSVWG for consideration because it discusses transport mappings to QoS.

I understand from the draft this proposes default mappings for an RTCWeb use cases. As I see it, the present draft:

* Advocates use of separate QoS code points for different streaming components

* Describes both endpoint handling of priority for the media and transport priority/precedence (aka DSCP).

* Proposes formalising a mapping between specific DSCPs and subnetwork QoS functions (LTE, WiFi - but not general Ethernet).

Please read this draft and comment on the list - we will table this for discussion at the next IETF meeting.

Gorry

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Sun, 14 Jul 2013 18:58:19 +0000

Wes,

In my view,  this draft important since it does provides guidance on a couple of fronts such as what the browser needs to do and what the application Javascript needs to do.  Also, it helps to clarify what inputs will be received from the application and what inputs are provided by the browser to the media engine. That is the key value of the draft. 

I understand that there will be an added complexity when the flow is no longer the traditional 5 tuple but a single flow can have multiple DSCP values. However, it is not a concept introduced by this draft. When applications have started allowing  multiplexing of different types of traffic into a single flow, the need has already been created. Not only in the webrtc space but also in the VDI space it is common to see flow that have multiplexed content. While we can restrict the QoS for multiplexed flows by saying only one DSCP allowed per flow, my experience has been that it is tremendously challenging for QoS to be relevant in such deployments.  

Having said the above, my draft does not either mandate a single or multiple DSCP for multiplexed flow.  One can always negotiate the lack of support for multiplexed flow in which case single flows will be used with one DSCP per flow.

Unfortunately, I will not be in Berlin. I am hoping that Cullen, Dan and you can chat some more if this continues to be an issue.

Regards,
Subha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Tuesday, July 09, 2013 7:57 PM
To: Cullen Jennings
Cc: DAN DRUTA; [email-masked]
Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

> The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it was an individual draft then WG draft in another WG and I don't think there is much more to say about it. This is one of…

Without checking ... it makes no sense to me that there would be a normative dependency on this since it does not impact the interoperability or correctness of an implementation.

It's purely a performance enhancement, if/when it actually causes the intended things to happen in the network.

That said, I think the interesting facet of this document is that packets within the same flow (defined by 5-tuple of address-port pairs and protocol number) are receiving different codepoints, and the implications of that for a CC that may be on top of them need to be delved into.  There isn't really text or recommendations going into that, which seems to be the important part, as if you can figure that out, these mappings are the more obvious part.

So, I think it might make sense to do this, but the current document isn't addressing the implications or how this works in a bigger system sense, and I don't think the particular marking tables are the hard or important part.

--
Wes Eddy
MTI Systems

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jul 2013 08:08:03 +1200

On 15/07/2013 06:46, Subha Dhesikan (sdhesika) wrote:
...
> The other challenge I see is with the relative position of the values being different from what is traditionally known for DSCP where EF> AF4x >AF3x>... How have you handled it so far in a non-web…

I don't track rtcweb and have no intention of doing so, but what on earth do you
mean by writing an inequality for DSCPs? DSCPs do not specify a priority
order; they identify (locally) a PHB, which is essentially a queuing disciplime.
Suggesting that EF is "greater" than an AF behaviour is just wrong.

   Brian

---

From: Andrew Mcgregor <[email-masked]>
Date: Mon, 15 Jul 2013 06:25:13 +1000

Nevertheless, specifying a priority order is exactly what tc_prio and
pfifo_fast do... I agree it's wrong, but that's what a very large number of
existing devices do right now, and ignoring that fact is likely to cause
problems.

Yes, this is unfortunately a mess, and I can't see a way to avoid that
completely.  The smaller set of codepoints I mention, AF42>AF33>AF21>(CS1
or BE), is not comprehensive, but is at least consistently ordered; the
tc_prio map unfortunately makes EF unusable because it ends up equivalent
to BE.

To clarify a little, I'm saying that AF42, AF32, AF22 and AF12 are all the
same so far as tc_prio is concerned, same for AF41, AF31, AF21 and AF11,
and the same for AF[1234]3.  So to get some consistency between the
schemes, I have chosen for example AF42, which is in the highest priority
band for both, AF33 for the second, AF21 for the third, and CS1 for the
fourth, although even that is not ideal because it puts AF21 in a
less-than-best-effort class while CS1 is equivalent to best-effort on the
linux-based devices.

There is considerable established practice within the game industry of
using QoS codepoints that do map to tc_prio bands.  Therefore there's a
commonly deployed base of both low-end routers and code that depend on that
behaviour, and attempting to standardise something that is inconsistent
with it seems like an exercise in futility.

I should point out that not every linux-based router does this, it is
certainly possible to get 4594 behaviour, or ignore the TOS bits entirely,
or do DPI to assign TOS, or remark, or pretty much any behaviour you might
imagine.  However, the majority of linux-based devices use very close to
the default configuration of the IP stack.

I believe rtcweb should be pragmatic about this, and accept that very
fine-grained marking is not going to fly in the majority of cases on the
edge of the internet, and take the benefits available from a restricted set
of codepoints that are at least widely available, reasonably consistent in
semantics, and commonly also result in correct behaviour from lower layers,
particularly 802.1p and 802.11e MAC QoS.

Andrew

On 15 July 2013 06:08, Brian E Carpenter <[email-masked]>wrote:

> > The other challenge I see is with the relative position of the values
> being different from what is traditionally known for DSCP where EF> AF4x
> >AF3x>... How have you handled it so far in a non-web rtc environment?
>

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 8143 7128

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jul 2013 08:51:39 +1200

> less-than-best-effort class while CS1 is equivalent to best-effort on the

In that case, the error is using the PHB names in the first place. The
behaviours you're describing are *not* the PHBs whose names you are using.
They need new names that describe them correctly.

To reiterate, the binding between a behaviour such as EF or AFxy and a particular
DSCP value is locally defined. If the behaviour is in fact simple preemptive
priority, please don't call it something else. The fact that Linux gets it
wrong doesn't mean IETF documents should be wrong too.

   Brian

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Sun, 14 Jul 2013 20:56:03 +0000

Brian,

What I mean by inequality and priority  is merely using words to describe the relationship described by Andrew.  The point is that if I mark something as EF I am expecting strict priority, a PHB that is not delivered by the AF class. Also, I don't expect that a packet marked with EF PHB to get a AF2x PHB.  Hence, perhaps, a poor choice of words but the essence refers to the behavior of what has been described as popularly deployed. 

This is why I have sought to understand from Andrew how this is being handled today.

Regards,
Subha

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Sunday, July 14, 2013 1:08 PM
To: Subha Dhesikan (sdhesika)
Cc: Andrew McGregor; [email-masked]; tsvwg
Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

> The other challenge I see is with the relative position of the values being different from what is traditionally known for DSCP where EF> AF4x >AF3x>... How have you handled it so far in a non-web…

I don't track rtcweb and have no intention of doing so, but what on earth do you mean by writing an inequality for DSCPs? DSCPs do not specify a priority order; they identify (locally) a PHB, which is essentially a queuing disciplime.
Suggesting that EF is "greater" than an AF behaviour is just wrong.

   Brian

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Sun, 14 Jul 2013 21:02:58 +0000

Inline:

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Sunday, July 14, 2013 1:52 PM
To: Andrew Mcgregor
Cc: Subha Dhesikan (sdhesika); [email-masked]; tsvwg; Andrew McGregor
Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

On 15/07/2013 08:25, Andrew Mcgregor wrote:
> pfifo_fast do... I agree it's wrong, but that's what a very large 
> number of existing devices do right now, and ignoring that fact is 
> likely to cause problems.
> 
> completely.  The smaller set of codepoints I mention, 
> AF42>AF33>AF21>(CS1 or BE), is not comprehensive, but is at least 
> consistently ordered; the tc_prio map unfortunately makes EF unusable 
> because it ends up equivalent to BE.
> 
> To clarify a little, I'm saying that AF42, AF32, AF22 and AF12 are all 
> the same so far as tc_prio is concerned, same for AF41, AF31, AF21 and 
> AF11, and the same for AF[1234]3.  So to get some consistency between 
> the schemes, I have chosen for example AF42, which is in the highest 
> priority band for both, AF33 for the second, AF21 for the third, and 
> CS1 for the fourth, although even that is not ideal because it puts 
> AF21 in a less-than-best-effort class while CS1 is equivalent to 
> best-effort on the linux-based devices.

In that case, the error is using the PHB names in the first place. The behaviours you're describing are *not* the PHBs whose names you are using.
They need new names that describe them correctly.

To reiterate, the binding between a behaviour such as EF or AFxy and a particular DSCP value is locally defined. If the behaviour is in fact simple preemptive priority, please don't call it something else. The fact that Linux gets it wrong doesn't mean IETF documents should be wrong too.

SD: Andrew, my original reaction was the same as above. Given that the some of these PHB have been defined for over a decade and RFC 4594 has also been around for some time, I could not imagine what concession my document can make to alleviate the problem without impacting all other application environments. However, if there is a precedence of how it is being handled, please share.

Regards,
Subha

   Brian

> using QoS codepoints that do map to tc_prio bands.  Therefore there's 
> a commonly deployed base of both low-end routers and code that depend 
> on that behaviour, and attempting to standardise something that is 
> inconsistent with it seems like an exercise in futility.
> 
> certainly possible to get 4594 behaviour, or ignore the TOS bits 
> entirely, or do DPI to assign TOS, or remark, or pretty much any 
> behaviour you might imagine.  However, the majority of linux-based 
> devices use very close to the default configuration of the IP stack.
> 
> fine-grained marking is not going to fly in the majority of cases on 
> the edge of the internet, and take the benefits available from a 
> restricted set of codepoints that are at least widely available, 
> reasonably consistent in semantics, and commonly also result in 
> correct behaviour from lower layers, particularly 802.1p and 802.11e MAC QoS.
> 
> Andrew
> 
> 
>> I don't track rtcweb and have no intention of doing so, but what on 
>> earth do you mean by writing an inequality for DSCPs? DSCPs do not 
>> specify a priority order; they identify (locally) a PHB, which is 
>> essentially a queuing disciplime.

---

From: Andrew Mcgregor <[email-masked]>
Date: Mon, 15 Jul 2013 10:15:56 +1000

On 15 July 2013 06:51, Brian E Carpenter <[email-masked]>wrote:

> the

Well, perhaps they do.  However, using the RFC 4594 names for the bit
patterns in the packets per figure 3 of that RFC, rather than the PHB
definitions, those particular bit patterns get vaguely compatible treatment
between some router behaving per RFC 4594 PHB definitions and something
running pfifo_fast.  That is my point.

Perhaps we need another description of what is going on here, that's a
separate question, but we have those five codepoints (and perhaps a few
more, I didn't do an exhaustive search) that produce sensible behaviour in
both RFC 4594 recommended behaviour and the more widely deployed pfifo_fast.

More sensible names might well be those originally from 802.11e or 802.1p,
whichever of those coined these, those being VO ('voice'), VI
('video/interactive'), BE ('best effort') and BK ('background'), in which
case we have from my earlier example:

RFC 4594 name -> 802 name (TOS bit pattern)
AF42 -> VO (100100)
AF33 -> VI (011110)
AF21 -> BK (010010)
BE -> BE (000000)
CS1 -> BE (001000) (possibly, the different code point in this case saying
'BE, and I really mean that, this is not just default')

Using this set of bit patterns, the queueing behaviour will be correct on
many, perhaps most, existing access networks AND the 802 layer queueing
will be correct as well on a subset of those.  This would be a win, in
general.  It will also cause something sensible to happen in a network
using the mapping from RFC 4594 figure 3.

To reiterate, the binding between a behaviour such as EF or AFxy and a
> particular

I believe that that local definition of the binding is a catastrophic bug
in the diffserv specs, and should never have been published in that form.
 However, too late now.  There is absolutely no way to tell an application
correctly what it should do with those bits unless there is an agreed set
of default meanings for at least some of the codepoints; maybe not total
specification of the exact behaviour, that's impractical, but at least a
way of setting some expectations.

If rtcweb continues with the code point recommendations in the draft as it
stands, code written to those recommendations will be quite seriously
broken when deployed.  The predictable outcome will be 'so turn off the
marking', and yet again an opportunity to do something sensible and
pragmatic with this feature is missed.  Let's not allow that to happen
simply because of terminology.  By saying 5 out of 64 codepoints should
have reasonable default behaviours, we might actually get this deployed.

> entirely,
> > On 15 July 2013 06:08, Brian E Carpenter <[email-masked]
> >wrote:
> >
> earth
> >> do you

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jul 2013 17:02:11 +1200

Andrew,

Just a few more points from me:

On 15/07/2013 12:15, Andrew Mcgregor wrote:
...
> separate question, 

Indeed we do, and it's called PHB Identifiers, which are intended for
naming PHBs in a globally unique way independent of the 6 bit DSCP
(RFC 3140).

It's a shame nobody uses them.

> but we have those five codepoints (and perhaps a few

Fair enough, but 4594 only works across provider boundaries if there is mutual
agreement.

...
> in the diffserv specs, and should never have been published in that form.

It was (at the time) an essentially non-negotiable requirement from
those in the diffserv WG who claimed to be operators who wanted
freedom to use the TOS field as they wished. If today's operators have
a different view, I don't see why this couldn't be revisited, but
that's off topic here and now.

> way of setting some expectations.

I agree, and this applies to any cross-domain use of the codepoints.
However, there are two caveats:

1. Use phrasing that recognises that the standard formally requires local
bindings.

2. Deal with the fact that these bits can be forged in the IP header.

  Brian