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

"Piers O'Hanlon" <p.ohanlon@gmail.com> Thu, 29 October 2015 15:26 UTC

Return-Path: <p.ohanlon@gmail.com>
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 B32DF1A8840; Thu, 29 Oct 2015 08:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.989
X-Spam-Level: *
X-Spam-Status: No, score=1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 33E8m5Iws8be; Thu, 29 Oct 2015 08:25:59 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9F21A8725; Thu, 29 Oct 2015 08:25:58 -0700 (PDT)
Received: by oifu63 with SMTP id u63so37920839oif.2; Thu, 29 Oct 2015 08:25:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rCLMcRPDv3sAbFoXS9+fu6LiYiHxlXeCRlr6lWHon80=; b=ivi68Mr7Qna03l7Prvp2CoC5mAsNu++AJ1wMANR8CfxuE/HMGcVomLwsFvhq5icve9 xN0wVC18pTnkC7t5HXbEvrgRbw1yjcS5t0YATdsv35CHLsC/b9srg3shxCoqKx7htDRZ Cq4g7gck3I0aqSl6ZwGo2CMcXYNYAnknw6Uw0Fz0woRNgq1LTiZDGPunnsOTXFEnJtVu zBHqnDOwUIv8+Hmkhq9Kh52JpkXYA5+UMBEUe+XrWKDPJr2A/nSJLVPJWDiK+XyZ30s/ pnOU4AZfyxbGkBuEznwa9FnuksGL0Jpzn0HUhj8xcUdRFgjn1IarRE0D8t4nbHpRuj3f 6WyQ==
X-Received: by 10.60.58.67 with SMTP id o3mr1646960oeq.48.1446132358236; Thu, 29 Oct 2015 08:25:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.88.215 with HTTP; Thu, 29 Oct 2015 08:25:38 -0700 (PDT)
In-Reply-To: <CAOJ7v-1RJbhe3i+_newDBObtJfJM6pWZUyRb4GZ8BHRDdDyKDg@mail.gmail.com>
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>
From: Piers O'Hanlon <p.ohanlon@gmail.com>
Date: Thu, 29 Oct 2015 15:25:38 +0000
Message-ID: <CAFWWCs5q2SnNnWrdmV910V+4LGP6kAYKQHAtHCNBcjmHRahC9g@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="089e0158b69a82d41b05233fedc4"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/nNZCNPzL4uu4hV_uBLknK0JaWQQ>
Cc: "Pal Martinsen (palmarti)" <palmarti@cisco.com>, Dave Taht <dave.taht@gmail.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] [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: Thu, 29 Oct 2015 15:26:01 -0000

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@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@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/
>>
>>
>>
>>
>>
>