<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">I’ll do what academics do and add our own data point, below:<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 23, 2019, at 4:19 PM, Roland Bless <<a href="mailto:roland.bless@kit.edu" class="">roland.bless@kit.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Mikael,<br class=""><br class="">On 23.03.19 at 11:02 Mikael Abrahamsson wrote:<br class=""><blockquote type="cite" class="">On Sat, 23 Mar 2019, Roland Bless wrote:<br class=""><br class=""><blockquote type="cite" class="">I suggest to use an additional DSCP to mark L4S packets.<br class=""></blockquote><br class="">DSCP doesn't work end-to-end on the Internet, so what you're suggesting<br class="">isn't a workable solution.<br class=""></blockquote><br class="">It's true that DSCPs may be remarked, but RFC 2474<br class="">already stated<br class=""><br class=""> Packets received with an unrecognized codepoint SHOULD be forwarded<br class=""> as if they were marked for the Default behavior (see Sec. 4), and<br class=""> their codepoints should not be changed.<br class=""><br class="">The rtcweb WG also counts on e2e DSCPs.<br class="">After the LE PHB experience I would suggest to probably use<br class="">DSCP 5 which has got better chances to survive ToS bleaching (maybe<br class="">around 80%), if I understand<br class=""><a href="https://www.sciencedirect.com/science/article/pii/S0140366417312835" class="">https://www.sciencedirect.com/science/article/pii/S0140366417312835</a><br class="">correctly. Diffserv behavior is usually configurable and can be changed<br class="">without replacing the network gear.<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><a href="https://itc-conference.org/_Resources/Persistent/780df4482d0fe80f6180f523ebb9482c6869e98b/Barik18ITC30.pdf" class="">https://itc-conference.org/_Resources/Persistent/780df4482d0fe80f6180f523ebb9482c6869e98b/Barik18ITC30.pdf</a></div><div><br class=""></div><div>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.</div><div>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).</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Cheers,</div><div>Michael</div><div><br class=""></div></div></div></div></body></html>