I’ll do what academics do and add our own data point, below:

On Mar 23, 2019, at 4:19 PM, Roland Bless <roland.bless@kit.edu> wrote:

Hi Mikael,

On 23.03.19 at 11:02 Mikael Abrahamsson wrote:
On Sat, 23 Mar 2019, Roland Bless wrote:

I suggest to use an additional DSCP to mark L4S packets.

DSCP doesn't work end-to-end on the Internet, so what you're suggesting
isn't a workable solution.

It's true that DSCPs may be remarked, but RFC 2474
already stated

  Packets received with an unrecognized codepoint SHOULD be forwarded
  as if they were marked for the Default behavior (see Sec. 4), and
  their codepoints should not be changed.

The rtcweb WG also counts on e2e DSCPs.
After the LE PHB experience I would suggest to probably use
DSCP 5 which has got better chances to survive ToS bleaching (maybe
around 80%), if I understand
https://www.sciencedirect.com/science/article/pii/S0140366417312835
correctly. Diffserv behavior is usually configurable and can be changed
without replacing the network gear.

Runa Barik, Michael Welzl, Ahmed Mustafa Elmokashfi, Thomas Dreibholz, Stein Gjessing: "Can WebRTC QoS Work? A DSCP Measurement Study", 30th International Teletraffic Congress (ITC 30), 3 - 7 September 2018, Vienna, Austria.

https://itc-conference.org/_Resources/Persistent/780df4482d0fe80f6180f523ebb9482c6869e98b/Barik18ITC30.pdf

We didn’t measure undefined codepoints though, only EF, AF42 and CS1. Table 2 compares bleaching for these codepoints with the results in the paper you point to; it’s quite similar.

Well yes, there’s a significant amount of bleaching, we can’t deny that. But sometimes the codepoint survives, and it seems to survive surprisingly long into the path (fig.4 in our paper).

In the MAPRG session in Prague, Runa Barik will give a talk about the measured delay impact of such opportunistic use of these DSCP values by an end system.

Cheers,

Michael