From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3B3503CB37 for ; Sat, 23 Mar 2019 14:32:10 -0400 (EDT) Received: by mail-ot1-x335.google.com with SMTP id x8so4697916otg.7 for ; Sat, 23 Mar 2019 11:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jPaoQyp+K7lxl2hVFWN/bqyzao77w+WmgBKjALVFG4o=; b=o5JZL7vaNeTsI4i8fGqpagoVnxInZxpQn5nVpomQGs6pJq275E65tHP00BaQV01QfA W+4glQC3qChTaKDNi490nW5g/WMWQVIx2V2BlT8ASNGlezzYz5E6sc5LFKBcWPRuJUKq li7VYMWt5N2IIf0QSgfSuqZjAA1UdbQ+ECMm+cx2sNfUCx6sBWkrtuY17u6FCjz9cwfU mZFhX1JD3brtnHwZ1RdHis5aD+sOF2uOCr+Q4DV7woTu7IPP6YprBg0mmoOJUQcGNVcq jBNhjUd4Hr0EAo3Yawr1/bGO4Cam+lglivNrRn+SxKKXmX4mOaLrEcuky0lpF+2JuH/5 z1hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jPaoQyp+K7lxl2hVFWN/bqyzao77w+WmgBKjALVFG4o=; b=Kv3FGe6BjhJoOvBBUk+ADc2HuGoVhMpmEpIgma02ePeV0+Yrl9JT8mTiiUwgxsouJk qLGbsAF3e4Kux5tQgItbwlC68ArHO4N67OaMlQTt3qk9ngqU0G8ys6r/Wyoq8C17Dmqc ItecqRNnHRInhcuB8B/NWzqaNTqm00TxZsg/BITxvji/3Z5pKJxWPuhoq3uDwbc7Zbfd NWEeZBCBqcdPKl9y3WJRt+Ft8Zb3AttgePco8Jz7b3aCbNfioPRwyL730ZRBGX5h5/Mv 8pcOKKPE4VIXqtURbLZgpEkimev03tZiHHgzzxkE+5gzQ4++O/PtnyejNAec+4pCmwrn A1uQ== X-Gm-Message-State: APjAAAWm6a7bTz/xUpOraBp4NFWW1ZmDFHjpc9hdGmKYzpbzzmpHGtFR SZ+yHCK25RfhUClynV901dPDuBI2nDM7PIWfe80= X-Google-Smtp-Source: APXvYqyWSkn6HnemxITKwifpG7L354wJRGY8lLOV7/p6BfdA4Q//FgfjzyfVOZXzXvPokJxGhnj1qLRYCTi+60nsnBw= X-Received: by 2002:a9d:1e8:: with SMTP id e95mr7206134ote.208.1553365929473; Sat, 23 Mar 2019 11:32:09 -0700 (PDT) MIME-Version: 1.0 References: <2c8ad5fe4be5c52ad1a3c2bf7f91a09a@mail.gmail.com> <00674bef-877b-3ccc-9c8e-e7e06ee8e1cd@kit.edu> <00a6bc91-22f2-8971-cec9-8aed615d632b@kit.edu> In-Reply-To: From: Luca Muscariello Date: Sat, 23 Mar 2019 19:31:57 +0100 Message-ID: To: Michael Welzl Cc: Roland Bless , Victor Hou , bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000006ebcbd0584c730e6" 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 18:32:10 -0000 --0000000000006ebcbd0584c730e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable WebEx, WebRTC they use it. QoS works. To answer the question in the title of Michael=E2=80=99s paper. It the app runs in the cloud and the cloud has direct peering links to your branch office or SP most likely DSCP works. And going back to Roland=E2=80=99s proposal, it seems the most natural appr= oach instead of hacking the semantics. On Sat 23 Mar 2019 at 18:48, Michael Welzl wrote: > 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: > > 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/780df4482d0fe80f6180f523= ebb9482c6869e98b/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= =99t deny that. > But sometimes the codepoint survives, and it seems to survive surprisingl= y > 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 a= n > end system. > > Cheers, > Michael > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --0000000000006ebcbd0584c730e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
WebEx, WebRTC they use it.
QoS works. To answer the question in the title of Michael=E2=80=99s pap= er.

It the app runs in t= he cloud and the cloud has direct peering links to your branch office or SP= =C2=A0
most likely DSCP works.

And going back to Roland=E2=80=99s proposal, = it seems the most natural approach instead of hacking the semantics.
<= div dir=3D"auto">

On Sat 23 Mar 2019 at 18:48, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

I=E2=80=99ll do what academ= ics do and add our own data point, below:

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

Hi Mikael,

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

<= blockquote type=3D"cite">I suggest to use an additional DSCP to mark L4S pa= ckets.

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
alread= y stated

=C2=A0=C2=A0Packets received with an unrecognized codepoin= t SHOULD be forwarded
=C2=A0=C2=A0as if they were marked for the Defaul= t behavior (see Sec. 4), and
=C2=A0=C2=A0their codepoints should not be= changed.

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

Runa Barik, Michael Welzl, Ahmed Mustafa E= lmokashfi, Thomas Dreibholz, Stein Gjessing: "Can WebRTC QoS Work? A D= SCP Measurement Study", 30th International Teletraffic=C2=A0Congress (= ITC 30), 3 - 7 September 2018, Vienna, Austria.

We didn=E2=80=99t measure undefined codepoin= ts though, only EF, AF42 and CS1. Table 2 compares bleaching for these code= points with the results in the paper you point to; it=E2=80=99s quite simil= ar.
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 se= ems to survive surprisingly long into the path (fig.4 in our paper).
<= div>
In the MAPRG session in Prague, Runa Barik will give a t= alk about the measured delay impact of such opportunistic use of these DSCP= values by an end system.

Cheers,
Michae= l

_____________________________= __________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--0000000000006ebcbd0584c730e6--