Hi Justin,

On Oct 22, 2015, at 21:54 , Justin Uberti <[email protected]> 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 <[email protected]> wrote:
>> On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) <[email protected]> 
>> wrote:
>> 
>> 
>>> On 21 Oct 2015, at 18:10, Harald Alvestrand <[email protected]> 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
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>> 
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> 
> _______________________________________________
> Cake mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake

_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to