[aqm] ECN support for UDP (was RE: [rmcat] [rtcweb] Catching up on diffserv markings)

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Fri, 23 October 2015 08:40 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A7CDB1B3344; Fri, 23 Oct 2015 01:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SY2EnnvTZGr9; Fri, 23 Oct 2015 01:40:32 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274631B3337; Fri, 23 Oct 2015 01:40:30 -0700 (PDT)
X-AuditID: c1b4fb30-f79626d000006adf-e5-5629f27c1c6e
Received: from ESESSHC012.ericsson.se (Unknown_Domain []) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.FF.27359.C72F9265; Fri, 23 Oct 2015 10:40:29 +0200 (CEST)
Received: from ESESSMB205.ericsson.se ([]) by ESESSHC012.ericsson.se ([]) with mapi id 14.03.0248.002; Fri, 23 Oct 2015 10:40:28 +0200
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Colin Perkins <csp@csperkins.org>, "Pal Martinsen (palmarti)" <palmarti@cisco.com>, Dave Taht <dave.taht@gmail.com>
Thread-Topic: ECN support for UDP (was RE: [rmcat] [rtcweb] Catching up on diffserv markings)
Thread-Index: AdENa5mK943I69uaQMma3cH7eCfP0w==
Date: Fri, 23 Oct 2015 08:40:26 +0000
Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3A@ESESSMB205.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3AESESSMB205erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM+JvjW7tJ80wg/lRFmv2SVpM/bqS1WL5 yxOMFns2nmSxeH99JYvF6psf2CzW/mtnd2D3mPJ7I6vHtPv32Tx2zrrL7rFkyU8mj+0XzzAF sEZx2aSk5mSWpRbp2yVwZexetYqp4Ns7xopdU1cxNjBeeMHYxcjJISFgIrH09zRmCFtM4sK9 9WwgtpDAUUaJW6/0uhi5gOwljBKLDu9iAkmwCdhIrDz0HaxZRKBSYk3/TSaQImaBR4wSS/f9 A+sWFoiSWLd7CVARB1BRvMT925YQ9XoS/VMeg4VZBFQldh1NBDF5BXwlfp4VBKlgFJCVuP/9 HguIzSwgLnHryXwmiNMEJJbsOQ91pqjEy8f/WCFsRYn2pw2MEPX5EjMOLQOL8woISpyc+YRl AqPwLCSjZiEpm4WkbBbQFcwCmhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxUm66 kZFealFmcnFxfp5eXmrJJkZgJB7c8ttgB+PL546HGAU4GJV4eBdM0QwTYk0sK67MPcQowcGs JMK7+z1QiDclsbIqtSg/vqg0J7X4EKM0B4uSOG8z04NQIYH0xJLU7NTUgtQimCwTB6dUA+Ns V62LYc3rjV546Qba3PH79cluaZPni6PLmoxzT937JM3T8DTDXWrvlpT6SXOvLdxlpPnz0fOa 5ZqFAnamXr9dlu8P2nX77smZh05obhAoYHiRbnmykcM6fM0vw6/z7rjm+H6u/8To1CfKrx/m 8NBYRp6pr0T01zovvgre0idn/CafmzfF5KgSS3FGoqEWc1FxIgAX0RZRwAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/WcS-YH4BA4u3IsJ1rMh5zX7tbew>
Cc: "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>, "rmcat@ietf.org" <rmcat@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>
Subject: [aqm] ECN support for UDP (was RE: [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: Fri, 23 Oct 2015 08:40:35 -0000

A followup on the ECN discussion :

Congestion control wise (RMCAT) both NADA and SCReAM support ECN in the specification. In addition MTSI (3GPP SA4) support ECN in the specification.
In SCReAM, the support is not fully implemented in running code but he feedback is in place and the additional amount of code needed to get ECN support is very small. The latest specification however explains the ECN support, the behavior is very similar to RFC3168 as SCReAM is a self-clocked protocol.
The current snag is that the sockets need to be modified to give access to the two ECN bits. More specifically, what is needed is to be able to set the two ECN bits and to read the same two ECN bits in the IP header, this is also stated in section 9 in RFC6679 . Here I believe that one can easily spend more time discussing the good and bad sides of adding ECN support to the socket interface than it actually takes to implement it ☺ .

Network wise, I guess the support for ECN for UDP is a matter of configuration, but if one look from strict radio (LTE) perspective it does not really matter if it is UDP or TCP over IP, it is treated the same, thus the strategy for ECN marking should be the same and should preferably follow the guidelines in RFC7567.


From: Colin Perkins [mailto:csp@csperkins.org]
Sent: den 22 oktober 2015 11:14
To: Pal Martinsen (palmarti)
Cc: cake@lists.bufferbloat.net; rmcat@ietf.org; rtcweb@ietf.org; Dave Taht; aqm@ietf.org
Subject: Re: [rmcat] [rtcweb] Catching up on diffserv markings

On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) <palmarti@cisco.com<mailto:palmarti@cisco.com>> wrote:

On 21 Oct 2015, at 18:10, Harald Alvestrand <harald@alvestrand.no<mailto: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.


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

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


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 :-)


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.

rtcweb mailing list

rtcweb mailing list

rtcweb mailing list

Colin Perkins