Re: [aqm] [Cake] [rmcat] [rtcweb] Catching up on diffserv markings

Sebastian Moeller <moeller0@gmx.de> Tue, 27 October 2015 08:06 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439201B37C1; Tue, 27 Oct 2015 01:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.35
X-Spam-Level:
X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkcAPvE0Fnjw; Tue, 27 Oct 2015 01:06:47 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046EA1B37BF; Tue, 27 Oct 2015 01:06:47 -0700 (PDT)
Received: from u-089-d065.biologie.uni-tuebingen.de ([134.2.89.65]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LqylH-1aTsnI1wyh-00ecJH; Tue, 27 Oct 2015 09:06:43 +0100
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <CAOJ7v-1RJbhe3i+_newDBObtJfJM6pWZUyRb4GZ8BHRDdDyKDg@mail.gmail.com>
Date: Tue, 27 Oct 2015 09:06:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AE5EAF1-4177-466F-AEFA-3198F03F24B7@gmx.de>
References: <CAA93jw64CVt6wvexRfpmaF1gFk-iegKSJxQscjccRSZ0yshvsQ@mail.gmail.com> <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> <CAOJ7v-1RJbhe3i+_newDBObtJfJM6pWZUyRb4GZ8BHRDdDyKDg@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
X-Mailer: Apple Mail (2.1878.6)
X-Provags-ID: V03:K0:u4BMFdfeICW8r4GD0kEABVxhGSMXnpy1ifRNVzWxjjBe8MBHhZw QXH267cgGYblqL+b789QUvRe2tkXcQyCjd9PiwvWOruO4Fftg/8+73MbVGYGAT+oghFkbgP 02+nTi5o0SOLsaTGH0ZS6IwDspASyZ/zVPlN1d44xnhck/V90lpiSx5lhTftPCs9pxO6Cz+ sNi6O20fSlKomvULp7woQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:rFEWZKM8324=:BzE1fYQaZJIzjPnsO5qql6 TsS820dEY3urCIY7jhBhQEkc15TB6UclMmKkvXBMLZFJkU9prabx1sZfgSB9He6gLiF+KJb0Y fzjLHABAKCVtZs35SBOSQAo6d5A73JOUMCZr4wIk+o5p1mWBGHNPvV5juAXNekwZRtNBbVP5T LIjAF9bD99SkxPb/p/9NHQtUaUNbbpo7buD68qKFa5Pac6pJOK7RqKJ/HbpCBf0sFk5DqIuJ/ IDt6HgYNqRJ4Z8oGOAcfweGlyisRLXFMWWnuy1FiHxyPHJGGk1rBLBOR0IXPYsGjZRopuiuWB UBnoW8Tgbk9m04RuMGb4IZw9JgEM2nMQ2H4/jVNeIbFgGLkgp+n2uachUbeKwckXKT7v+PwuG wCEFm8QYwplXB4NlShTLm+vPrv1OzlsCTmk6wDoF0klx46HUlQuQXbD+ltEhOcFvOBYt2S7Tz CBYQh4v1HMshE/6C4KGrjXdo0UuNrcqXcr4fKuDALq2da/vhfHOb6GhuJEuMOn830Ig+JJZ/O DhNHCc7tFJNsR9D+gTdJy2HOwiERlD7HZ0VpyX2Z726olXcT3A7kDpsapqebBcYqE+U4egRsJ Qrkq6fcWBbpPj5NgW5FsYGocYMgB9Y+AdOyP0ZZePqLTG29jrThQBKN4+2Pq+IdU2xmaP9dvg pSkHH7QEJqX3wS2zXDfefWAO2GnAsmoI9MipsL8tCyVwqhbiIaTOt8fkOcTwxd+T0ZmAOuAqY JPFFLVVRIWRTQosJMaYBVT7u/f8gB64R+IiF5p91I328EZUT6qZOXffRwwx0AjGfUAkGOwB1o mC/Mu6R
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/2ttfV9ECl-OaJ8qKcQUkrCUp2dw>
X-Mailman-Approved-At: Sat, 31 Oct 2015 08:56:43 -0700
Cc: "Pal Martinsen (palmarti)" <palmarti@cisco.com>, "aqm@ietf.org" <aqm@ietf.org>, "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>, "rmcat@ietf.org" <rmcat@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [aqm] [Cake] [rmcat] [rtcweb] Catching up on diffserv markings
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2015 08:36:20 -0000

Hi Justin,


On Oct 22, 2015, at 21:54 , Justin Uberti <juberti@google.com> wrote:

> At present I'm not aware of any widely-deployed OS where an app can read the received ECN markings. 
> 
> iOS9 added support for this within the kernel, and it's used for TCP, but not exposed to userspace. There is an open Radar bug asking for this info to be exposed to userspace.
> 
> FWIW, Chrome supports setting the DSCP markings if you set a magic parameter. But it's not on by default, mainly because we've never done the auditing necessary to ensure this doesn't randomly break in various dimly-lit parts of the internet.

	Slightly related question, is this DSCP marking capability restricted to webrtc packets or is there a way to make chrome use (arbitrary) DSCP marks for all its packets? For exercising different priority banding schemes such an option would be perfect (say to test whether a aqm+qos system will allow snappy browsing even with heavy download/upload/bittorrent traffic in other priority bands; this test is especially interesting if all traffic sources can reside on the same host, as this is a quite common set-up in home networks, one computer that does everything concurrently and where the users still want a decent browsing experience).

Best Regards
	Sebastian


> 
> On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins <csp@csperkins.org> wrote:
>> On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:
>> 
>> 
>>> On 21 Oct 2015, at 18:10, Harald Alvestrand <harald@alvestrand.no> wrote:
>>> 
>>> Den 21. okt. 2015 17:51, skrev Dave Taht:
>>>> I unsubscribed from rmcat and rtcweb groups a while back after I got
>>>> overloaded, and appear.in started working so well, (for both ipv6 and
>>>> ipv4! I use it all day long now!), to focus on finishing up the new
>>>> "cake" qdisc/shaper/aqm/QoS system, among other things.
>>>> 
>>>> http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical
>>>> 
>>>> Cake is now entering the testlab, and among other things, it has
>>>> support for the diffserv markings discussed in the related, now
>>>> concluded dart wg, but in ways somewhat different from that imagined
>>>> there. We have not got any good code in our testbeds yet to test
>>>> videoconferencing behavior, and we could use some, although it does
>>>> look like we can drive firefox with some remote control stuff with a
>>>> fixed video playback now....
>>>> 
>>>> Five questions:
>>>> 
>>>> 1) Has anyone implemented or tested putting voice and video on two
>>>> different 5-tuples in any running code out there?
>>> 
>>> All VC systems I know of except WebRTC-based ones do it, AFAIK.
>>> It’s putting them on the same that's unusual.
>>> 
>> That sounds like the world I am living in as well.
>> 
>> 
>>>> 2) How about diffserv markings in general? Do any browsers or webrtc
>>>> capable software support what was discussed way back when?
>>> 
>>> I know Hangouts did something like that internally, on the controlled
>>> network. But not according to spec.
>>> 
>>>> 3) Were diffserv marking changes eventually allowed on the same 5-tuple?
>>> 
>>> Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table.
>>> 
>>>> 4) Did the ECN support that was originally in one draft or another
>>>> ever make it into any running code?
>>> 
>>> I don't know. I think we lost it from the docs.
>>> 
>>>> (yea, apple plans to turn on ecn universally in their next OS!)
>>>> 
>> So how would ECN work on UDP? I do not think the necessary bits from the IP header are available for the application to do anything. I do think Linux supports this, have not tested.
>> 
>> And what about the network, would it support UDP when setting the ECN bits? Probably a configuration related problem if not supported.
> 
> RFC 6679 describes how to use ECN with RTP on UDP, although as you say there are implementation difficulties on some platforms. I’m not sure whether there are implementations. 
> 
> 
>>>> 5)  What else did I miss in the past year I should know about?
>>> 
>>> For TCP and SCTP congestion controllers, we're back to one DSCP marking
>>> per flow, and resetting the congestion control state if DSCP marking
>>> changes.
>>> 
>> 
>> There is a new ICE wg. It was created so “network people” could participate without the overhead of listening to the SDP related discussions. (https://datatracker.ietf.org/wg/ice/charter/)
>> 
>> .-.
>> Pål-Erik
>> 
>>>> 
>>>> Feel free to contact me off list if these have already been discussed.
>>>> I have totally lost track of the relevant drafts.
>>> 
>>> They're not finished still :-)
>>> 
>>>> 
>>>> Sincerely,
>>>> 
>>>> Dave Täht
>>>> I just lost five years of my life to making the edge
>>>> of the internet, and, wifi better.
>>>> And, now... the FCC wants to make my work illegal
>>>> for ordinary people to install.
>>>> https://www.gofundme.com/savewifi
>>>> 
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>> 
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake