From: Colin Perkins <csp@csperkins.org>
To: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
Cc: "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>,
"rmcat@ietf.org" <rmcat@ietf.org>,
"rtcweb@ietf.org" <rtcweb@ietf.org>,
"aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [Cake] [rtcweb] Catching up on diffserv markings
Date: Thu, 22 Oct 2015 10:13:33 +0100 [thread overview]
Message-ID: <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> (raw)
In-Reply-To: <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com>
[-- Attachment #1: Type: text/plain, Size: 4256 bytes --]
> 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 <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.
>>>
>>> http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical <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/ <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 <https://www.gofundme.com/savewifi>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rtcweb <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/
[-- Attachment #2: Type: text/html, Size: 24493 bytes --]
next prev parent reply other threads:[~2015-10-22 9:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-21 15:51 [Cake] " Dave Taht
2015-10-21 16:10 ` [Cake] [rtcweb] " Harald Alvestrand
2015-10-22 7:48 ` Pal Martinsen (palmarti)
2015-10-22 9:13 ` Colin Perkins [this message]
2015-10-22 19:54 ` [Cake] [rmcat] " Justin Uberti
2015-10-23 13:29 ` Jonathan Morton
2015-10-23 13:31 ` Loganaden Velvindron
2015-10-27 8:06 ` Sebastian Moeller
2015-10-27 16:16 ` Justin Uberti
2015-10-27 17:04 ` Sebastian Moeller
2015-10-29 15:25 ` Piers O'Hanlon
2015-10-22 20:02 ` [Cake] [aqm] " Christian Huitema
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org \
--to=csp@csperkins.org \
--cc=aqm@ietf.org \
--cc=cake@lists.bufferbloat.net \
--cc=palmarti@cisco.com \
--cc=rmcat@ietf.org \
--cc=rtcweb@ietf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox