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

From: Dave Taht <[email-masked]>
Date: Sun, 29 Dec 2013 16:02:08 -0800

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

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.

In current implementations, is it possible to force flows onto
different tuples? 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)

Some comments on section 3

        A.  If possible, it should also share information and adaptation
            with other non-RTP flows between the same endpoints, such as
            a WebRTC data channel

I might argue that looking at the traffic on the whole browser would
be good. The browser deprioritizing background web page loads while a
webrtc session is active would be useful in the presence of
congestion.

        B.  The most correlated bandwidth usage would be with other
            flows on the same 5-tuple, but there may be use in
            coordinating measurement and control of the local link(s).

As I note above you can get more congestion information from a pair of
flows than one.

        C.  Use of information about previous flows, especially on the
            same 5-tuple, may be useful input to the algorithm,
            especially to startup performance of a new flow.

A 4 tuple may also provide insight, or even two (ip to ip)

        4B.  When additional input signals such as ECN are available,
            they should be utilized if possible.

I would not mind seeing an implementation that negotiated ECN, but it
is out of scope on this document. Is it discussed elsewhere, or
implemented elsewhere? Is an ipv6 version of webrtc implemented
anywhere? I am under the impression it can be made to work in
freeswitch...

   6.   Flows managed by this algorithm and flows competed against at a
        bottleneck may have different DSCP markings depending on the
        type of traffic.  A particular bottleneck or section of the
        network path may or may not honor these markings.

And in fact, may not preserve them. It would be good to be aware
if they are being preserved in both directions and mark appropriately,
and also to probe if packets with particular classifications are being
dropped
or treated weirdly. This includes detecting for e2e ECN awareness.

        A.  In WebRTC, a division of packets into 4 classes is
            envisioned in order of priority: faster-than-audio, audio,
            video, best-effort, and bulk-transfer.  Typically the flows
            managed by this algorithm would be audio or video in that
            heirarchy, and feedback flows would be faster-than-audio.

faster-than-audio? RTCP Signalling? what?

I still have to think about RTCP signalling as it's very hard to pick
out of the data I have, if it's even in there.

   10.  The algorithm should quickly adapt to initial network conditions
        at the start of a flow.  This should occur both if the initial
        bandwidth is above or below the bottleneck bandwidth.

The algorithm I looked over has particularly bad behavior on taking
back bandwidth after it has been used up by another flow, taking many
seconds to ramp up. I like the idea of periodically probing to ratchet
up to a higher rate, with a slow-start-like burst (a higher resolution
frame sent in parallel with lower rate data).  But in terms of the
requirements, adding a

        The algorithm should quickly recover from a loss in bandwidth,
recovering voice first, if possible.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Dec 2013 15:09:35 +0100

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.

> (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.

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

---

From: Michael Welzl <[email-masked]>
Date: Mon, 30 Dec 2013 17:59:52 +0100

Sent from my iPhone

> could provide insight as to the congestion in the system.

that's why we want to couple the congestion controllers in such cases. no need for queuing to regulate fairness, you do it in the sender!

---

From: Dave Taht <[email-masked]>
Date: Mon, 30 Dec 2013 22:37:49 -0800

On Mon, Dec 30, 2013 at 6:09 AM, Harald Alvestrand <[email-masked]> wrote:
> 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.
>
>
>
> 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.

On a per packet level, voice is typically one packet ranging in size
from 110 bytes to 300 every 10 or 20ms. (the opus codec goes down to
2.5ms) Video, in comparison, consists of a variable number of (often)
many packets depending on encoding, subframes, etc.

So from this viewpoint voice can be isochronous (lacking silence
suppression), and video is not.

> 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.

jitter and loss on voice is often quite annoying. On music it's intolerable.

On video, I would not use the word "stuttering" which implies a
max-headroom sort of effect. Partial corruption of the output, blocky
output, etc are closer to words I would use.

> How does this effect happen?

Could you be more specific?

> elements "know" what the flows contain?

In nearly any packet scheduled system (drr, sfq,sqf, fq_codel, etc),
the separation of flows on a 5 tuple will result in (much) less delay,
jitter and loss for the lower rate flows. With sqf and fq_codel, if
the rate is low enough there will be near zero queuing delay, jitter
and loss on many workloads.

I try to encourage people to just try it to get a feel for what
happens. openwrt, cerowrt, any modern linux for all of the above,
cisco routers do drr, many dsl devices do sfq or sqf in their
firmware....

separation of flows does nothing terrible useful on a strict drop tail
system, but no harm either.

> What about multiplexing between different flows of the same media type?

Good question. There are many things I don't understand about webrtc's
intended audience.

What excites me most about it is the ability to do in-the-building
videoconferences without having to go over the internet for them.  As
for going over the internet... I think the cable industry is too
broken (currently) for any e2e congestion control algorithm to work at
all with serious cross traffic, with up and downlinks having 2 or more
seconds of buffering each. (unless fixed by one of the algorithms
above in a 3rd party router) FIOS and DSL users have a fighting
chance, 3g and LTE less so, and wifi needs some serious work.

So at the moment I'd like to be addressing the fixable e2e problems in
gcc (it can't even compete with itself!) and wanted to be able to
break things out on tuples to look at the data...

before drawing any conclusions on how to multiplex video flows.

My gut tells me you want one tuple per voice and per video flow, AND
to manage their congestion indicators together, but depending on the
level of statistical multiplexing of the video flows they could go on
a single tuple.

> Absolutely - just don't negotiate bundling.

Pointer to a working example?

keep hoping there's working ipv6 code out there too, getting the stun
and turn stuff out of the loop long enough to look at simpler cases.

> 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?

My understanding of the use case for that is that it is for p2p file
transfer. Given how prone to failure setup has been for this in other
protocols it seems to make some sense to bundle it on the video
tuple...

-- 
Dave Täht