From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D58B03CB37 for ; Sat, 23 Mar 2019 13:48:49 -0400 (EDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h7klB-0001Tu-Tc; Sat, 23 Mar 2019 18:48:45 +0100 Received: from 58.116.34.95.customer.cdi.no ([95.34.116.58] helo=[10.0.0.9]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1h7klB-0004dC-1k; Sat, 23 Mar 2019 18:48:45 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0598082F-BE8E-4D5B-AF97-4183C8D42BF0" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sat, 23 Mar 2019 18:48:44 +0100 In-Reply-To: <00a6bc91-22f2-8971-cec9-8aed615d632b@kit.edu> Cc: Mikael Abrahamsson , Victor Hou , bloat@lists.bufferbloat.net To: Roland Bless References: <2c8ad5fe4be5c52ad1a3c2bf7f91a09a@mail.gmail.com> <00674bef-877b-3ccc-9c8e-e7e06ee8e1cd@kit.edu> <00a6bc91-22f2-8971-cec9-8aed615d632b@kit.edu> X-Mailer: Apple Mail (2.3445.102.3) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 95.34.116.58 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.116.58; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.9]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EEF33AF72E3AAEB6210FBC370A99C7E06F3895AD Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 17:48:50 -0000 --Apple-Mail=_0598082F-BE8E-4D5B-AF97-4183C8D42BF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99ll do what academics do and add our own data point, below: > On Mar 23, 2019, at 4:19 PM, Roland Bless = wrote: >=20 > Hi Mikael, >=20 > On 23.03.19 at 11:02 Mikael Abrahamsson wrote: >> On Sat, 23 Mar 2019, Roland Bless wrote: >>=20 >>> I suggest to use an additional DSCP to mark L4S packets. >>=20 >> DSCP doesn't work end-to-end on the Internet, so what you're = suggesting >> isn't a workable solution. >=20 > It's true that DSCPs may be remarked, but RFC 2474 > already stated >=20 > 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. >=20 > 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/780df4482d0fe80f6180f523e= bb9482c6869e98b/Barik18ITC30.pdf = We didn=E2=80=99t 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=E2=80=99s quite similar. Well yes, there=E2=80=99s a significant amount of bleaching, we can=E2=80=99= 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 --Apple-Mail=_0598082F-BE8E-4D5B-AF97-4183C8D42BF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80= =99ll 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/S014036641731= 2835
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.

We didn=E2=80=99t 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=E2=80=99s = quite similar.
Well yes, there=E2=80=99s a significant amount = of bleaching, we can=E2=80=99t 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

= --Apple-Mail=_0598082F-BE8E-4D5B-AF97-4183C8D42BF0--