[Cake] [rmcat] [rtcweb] Catching up on diffserv markings

Thu Oct 29 11:25:38 EDT 2015

I implemented some prototype software that read and set ECN for UDP packets
whilst working on RFC6679, but there's no published open-source code I'm
aware of that fully implements RFC6679. I reported my experiences to the
AVT list back in 2011, and I've updated them here:

To set ECN on Linux, BSD and OSX one can use IP_TOS socket option, with the
setsockopt() call, to set the relevant ECN bits of the TOS byte. On Windows
one can use a similar technique though firstly one has to enable TOS byte
setting by enabling a particular Registry key ( DisableUserTOSSetting=0
(see
https://msdn.microsoft.com/en-us/library/windows/desktop/dd874008%28v=vs.85%29.aspx
One could also probably use the libpcap write functionality.

To obtain the ECN bits from a packet one needs a mechanism to retrieve the
ECN bits from each packet. On Linux, one needs to firstly set the
IP_RECVTOS socket option on the receiving socket, and use the recvmsg()
call to receive a packet, and then retrieve the TOS byte from the
associated csmg structure returned by the recvmsg() call. This still works
with linux-4.2.3. On OSX/BSD there are no suitable socket options to
retrieve the ECN/TOS bits and one cannot use raw sockets as they do not
function for UDP/TCP sockets (they do work with ICMP), so one has to use
alternatives such the bpf interface, or a REDIRECT socket. Whilst on
Windows it seems that the only way to retrieve the ECN bits is via a raw
socket, or custom NDIS driver, though it's possible there's an API I'm
missing.

On 22 October 2015 at 20:54, Justin Uberti <juberti at 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.
>
> On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins <csp at csperkins.org> wrote:
>
>> On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) <palmarti at cisco.com>
>> wrote:
>>
>>
>> On 21 Oct 2015, at 18:10, Harald Alvestrand <harald at 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 at ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb at ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb at ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>> --
>> Colin Perkins
>> https://csperkins.org/
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20151029/8b93cab2/attachment-0002.html>