<div><div dir="auto">WebEx, WebRTC they use it.</div></div><div dir="auto">QoS works. To answer the question in the title of Michael’s paper.</div><div dir="auto"><br></div><div dir="auto">It the app runs in the cloud and the cloud has direct peering links to your branch office or SP </div><div dir="auto">most likely DSCP works.</div><div dir="auto"><br></div><div dir="auto">And going back to Roland’s proposal, it seems the most natural approach instead of hacking the semantics.</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat 23 Mar 2019 at 18:48, Michael Welzl <<a href="mailto:michawe@ifi.uio.no">michawe@ifi.uio.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi,<div><br></div><div>I’ll do what academics do and add our own data point, below:<br><div><div><br><blockquote type="cite"><div>On Mar 23, 2019, at 4:19 PM, Roland Bless <<a href="mailto:roland.bless@kit.edu" target="_blank">roland.bless@kit.edu</a>> wrote:</div><br class="m_-7485270178189269902Apple-interchange-newline"><div><div>Hi Mikael,<br><br>On 23.03.19 at 11:02 Mikael Abrahamsson wrote:<br><blockquote type="cite">On Sat, 23 Mar 2019, Roland Bless wrote:<br><br><blockquote type="cite">I suggest to use an additional DSCP to mark L4S packets.<br></blockquote><br>DSCP doesn't work end-to-end on the Internet, so what you're suggesting<br>isn't a workable solution.<br></blockquote><br>It's true that DSCPs may be remarked, but RFC 2474<br>already stated<br><br>   Packets received with an unrecognized codepoint SHOULD be forwarded<br>   as if they were marked for the Default behavior (see Sec. 4), and<br>   their codepoints should not be changed.<br><br>The rtcweb WG also counts on e2e DSCPs.<br>After the LE PHB experience I would suggest to probably use<br>DSCP 5 which has got better chances to survive ToS bleaching (maybe<br>around 80%), if I understand<br><a href="https://www.sciencedirect.com/science/article/pii/S0140366417312835" target="_blank">https://www.sciencedirect.com/science/article/pii/S0140366417312835</a><br>correctly. Diffserv behavior is usually configurable and can be changed<br>without replacing the network gear.<br></div></div></blockquote><div><br></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" target="_blank">https://itc-conference.org/_Resources/Persistent/780df4482d0fe80f6180f523ebb9482c6869e98b/Barik18ITC30.pdf</a></div><div><br></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></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></div><div>Cheers,</div><div>Michael</div><div><br></div></div></div></div></div>_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div></div>