Re: [rmcat] 5 tuples and rmcat-cc-requirements-01

[Harald Alvestrand <[e-mail]>]

Dave, this is interesting .... I think characterizing what the 
connection between type-of-traffic and applicable congestion is should 
be an rmcat issue, but may feed back into RTCWEB and even MMUSIC - so 
I'm sending this to rmcat only.


On 12/30/2013 01:02 AM, Dave Taht wrote:
> I finally had a chance to read over
>
> http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-01
>
> and also work at reproducing some of the difficulties present in the
> current implementation of chrome in light of the two papers presented
> at the last ietf on google congestion control. I went through tons of
> tests and packet captures that pretty much reproduced the legion of
> problems documented in
>
> https://speakerdeck.com/vr000m/evaluating-googles-congestion-control-for-webrtc
> and the other paper presented at ietf...
>
> and also fed webrtc traffic through the fq_codel and pie queue
> management systems (with pretty good results). I have tons of captures
> from each experiment if anyone wants them.
>
> So, I have some comments on this requirements document. (I'm new to
> paying attention on rmcat, so a few of my questions are probably
> answered by some document I haven't read yet. Steers appreciated. for
> all I know I'm on the wrong mailing lists too. Sorry)
>
> In particular, the flows I was looking at multiplexed voice and video
> on the same 5 tuple. I am curious as to the justification for this, as
> voice (without silence suppression) is isochronous and video is not.
> (is silence suppression used in webrtc?)

This is a curious statement - what characteristic are you thinking about 
when you say that voice is "isochronous" and video is not?
Both of them are produced one time-frame at a time, and both of them 
cause irritation at the receiver when the frames are displayed in 
anything but the same cadence.

I think the irritation from jitter on voice is quite a bit higher than 
on video, but stuttering video isn't a good thing either.

>
> To me, multiplexing these two very different flows on the same ports
> is not a good idea except under extreme port pressure, and not useful
> in ipv6 or in non-natted environments at all. Even in a natted
> environment, saving a single port is a false savings as (for example)
> dns lookups punch dozens of holes through nat on a regular basis.
>
> Requiring that in most or all cases these two flow types be on unique
> 5 tuples would give smarter queue management techniques on routers
> (like sfq, or sqf (deployed at FT), or fq_codel (deployed at
> free.fr)), a fighting chance. In particular it gives voice much higher
> probability for drop-and-delay free behavior, and analyzing the delta
> in drops and delay between a separate voice tuple and video tuple
> could provide insight as to the congestion in the system.
How does this effect happen?
In particular, does the separation of flows itself create lower loss 
probability for voice, or are you thinking of systems where the network 
elements "know" what the flows contain?

What about multiplexing between different flows of the same media type?
>
> In current implementations, is it possible to force flows onto
> different tuples?

Absolutely - just don't negotiate bundling.

>   What are the other flaws in suggesting or requiring
> a different tuple?


>
> (note I'm not suggesting bulk data traffic get unique 5 tuples per flow)

I wouldn't either.
In current deployments, it's multiplexed with the media traffic on the 
same 5-tuple too - what would you suggest advising it to be bundled 
with, and why?

(dropping the rest of the message - this should be enough for one thread)