Subject: [rmcat] Parameters for congestion control

From: Varun Singh <[email-masked]>
Date: Mon, 13 Nov 2017 06:41:30 +0000

Hi,

Was there a study done for the parameters needed for congestion control? I
know we debated this at length, were there slides created by  the
congestion control proponents, that I can reference.

>From the top of my head, I remember there’s
+ priority (needed by coupled congestion control)

I’m asking this for w3c input. They already have max bitrate, max
framearte, and degradation preference  degradation preference indicates
where the bits should be allocated: in maintaining frame rates or frame
sizes.

Feedback is appreciated To make sure we didn’t miss anything.

Cheers,
Varun.
-- 
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/

---

From: Michael Welzl <[email-masked]>
Date: Mon, 13 Nov 2017 16:44:46 +0800

Can I hijack this thread to talk about priority?

There was a thread about priority in rtcweb - someone asking for a float… coupled-cc can easily support a float, but Harald’s transport draft doesn’t support it. Opinions went back and forth for a bit...
I think we should get more WebRTC deployment and not more debate on small details that delays the work, so I don’t want to be a troublemaker and didn’t interfere with this discussion.
But, what is the view of people in rmcat about this?

Cheers,
Michael

> On Nov 13, 2017, at 2:41 PM, Varun Singh <[email-masked]> wrote:
> 
> Hi,
> 
> Was there a study done for the parameters needed for congestion control? I know we debated this at length, were there slides created by  the congestion control proponents, that I can reference. 
> 
> I’m asking this for w3c input. They already have max bitrate, max framearte, and degradation preference  degradation preference indicates where the bits should be allocated: in maintaining frame rates or frame sizes. 
> 
> Founder, CEO, callstats.io <http://callstats.io/>
> http://www.callstats.io <http://www.callstats.io/>
> 
> We are hiring!: www.callstats.io/jobs/ <http://www.callstats.io/jobs/>

---

From: Varun Singh <[email-masked]>
Date: Mon, 13 Nov 2017 12:51:02 -0800

Hi Michael,

> Can I hijack this thread to talk about priority?
Priority is already defined in the API document to the following levels:
high, medium, low, very-low.
These labels map to the text in the transport document

        Thus, when congestion occurs, a "high" priority flow will have the
        ability to send 8 times as much data as a "very-low" priority flow
if
        both have data to send. This prioritization is independent of the
        media type. The details of which packet to send first are
        implementation defined.

WEBRTC API:
https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype

> There was a thread about priority in rtcweb - someone asking for a float…
> coupled-cc can easily support a float, but Harald’s transport draft doesn’t
> support it. Opinions went back and forth for a bit...
> I think we should get more WebRTC deployment and not more debate on small
> details that delays the work, so I don’t want to be a troublemaker and
> didn’t interfere with this discussion.
While the API does not provide a float value, nonetheless, doesn't the
WebRTC stack or framework under the JS API have all the information to
convert the set labels in to a float values after the flows are assigned
values?

---

From: Michael Welzl <[email-masked]>
Date: Tue, 14 Nov 2017 11:01:33 +0800

> On Nov 14, 2017, at 4:51 AM, Varun Singh <[email-masked]> wrote:
> 
> Hi Michael,
> 
> On Mon, Nov 13, 2017 at 10:44 AM, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> Priority is already defined in the API document to the following levels: high, medium, low, very-low.
>         ability to send 8 times as much data as a "very-low" priority flow if

I know!   The coupled-cc text matches these as well.

> WEBRTC API: https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype <https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype>
> 
>  
> While the API does not provide a float value, nonetheless, doesn't the WebRTC stack or framework under the JS API have all the information to convert the set labels in to a float values after the flows are assigned values? 

Sure, but the point of that discussion was that the definition of these values (high, very-low, etc etc) is too rigid.
We could easily offer a much less rigid priority value - this is no problem at all for coupled-cc (or a scheduler, for that matter).

It is my understanding that the choices of high, very-low etc. were made for simplicity, to just decide on *something* and move forward. I respect that - but I also found it disappointing to see someone complaining about this not supporting more flexible value choices when technically, we can easily do so…

Cheers,
Michael

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 14 Nov 2017 21:37:51 +0000

Hi

SCReAM supports a float priority value, in reality though I doubt that there is much benefit to have a higher granularity than the given values as we deal with live encoding with video coders that often produce a messy output. In the presentation today you’ll see an example of prioritization in the wild (page 12 in https://datatracker.ietf.org/meeting/100/materials/slides-100-rmcat-scream-experiments/ )

/Ingemar

From: Varun Singh [mailto:[email-masked]]
Sent: den 14 november 2017 04:51
To: Michael Welzl <[email-masked]>
Cc: Zaheduzzaman Sarker <[email-masked]>; [email-masked]; Colin Perkins <[email-masked]>; W3C@CSIO <[email-masked]>
Subject: Re: [rmcat] Priority and rtcweb

Hi Michael,

On Mon, Nov 13, 2017 at 10:44 AM, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:
Can I hijack this thread to talk about priority?

WEBRTC API: https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype

Cheers,
Michael

On Nov 13, 2017, at 2:41 PM, Varun Singh <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers,
Varun.
--
Founder, CEO, callstats.io<http://callstats.io/>
http://www.callstats.io<http://www.callstats.io/>

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/<http://www.callstats.io/jobs/>

--
Founder, CEO, callstats.io<http://callstats.io>
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/<http://www.callstats.io/jobs/>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 15 Nov 2017 06:41:04 +0100

On 11/13/2017 09:44 AM, Michael Welzl wrote:
> There was a thread about priority in rtcweb - someone asking for a
> float… coupled-cc can easily support a float, but Harald’s transport
> draft doesn’t support it. Opinions went back and forth for a bit...
> I think we should get more WebRTC deployment and not more debate on
> small details that delays the work, so I don’t want to be a
> troublemaker and didn’t interfere with this discussion.

the reason for the 4 levels was indeed that they were defined at a time
when we thought that any underlying system (whether it be diffserv or
congestion controllers that supported float priorities) could do
something sensible with them, while having more than 4 things to choose
from seemed to be of questionable value in a large majority of use cases.

a float doesn't help much if you don't know what the effect of changing
the value is; is it linear in bandwidth, linear in bandwidth fraction 
(sum and normalize? 0..1?), exponential in some dimension, logarithmic
in some other dimension?

If a congestion controller mechanism wants to interface to the webrtc 4
levels, it would have to do something like the diffserv-to-priority
document from TSV - defining what controls on the congestion controller
one needs to set to have an appropriate result on what gets sent when
congestion happens.

>> Was there a study done for the parameters needed for congestion
>> control? I know we debated this at length, were there slides created
>> by  the congestion control proponents, that I can reference. 
>>
>> framearte, and degradation preference  degradation preference
>> indicates where the bits should be allocated: in maintaining frame
>> rates or frame sizes. 
>>

-- 
Surveillance is pervasive. Go Dark.

---

From: Varun Singh <[email-masked]>
Date: Wed, 15 Nov 2017 22:51:27 +0000

Thanks, I'll check it out. Since I didn’t remotely participate in the
meeting today, Was there any input from the room?
On Tue, 14 Nov 2017 at 23.37, Ingemar Johansson S <
[email-masked]> wrote:

> Hi
>
>
>
> SCReAM supports a float priority value, in reality though I doubt that
> there is much benefit to have a higher granularity than the given values as
> we deal with live encoding with video coders that often produce a messy
> output. In the presentation today you’ll see an example of prioritization
> in the wild (page 12 in
> https://datatracker.ietf.org/meeting/100/materials/slides-100-rmcat-scream-experiments/
> )
>
>
>
> /Ingemar
>
>
>
>
>
> *From:* Varun Singh [mailto:[email-masked]]
> *Sent:* den 14 november 2017 04:51
> *To:* Michael Welzl <[email-masked]>
> *Cc:* Zaheduzzaman Sarker <[email-masked]>;
> [email-masked]; Colin Perkins <[email-masked]>; W3C@CSIO <
> [email-masked]>
> *Subject:* Re: [rmcat] Priority and rtcweb
>
>
>
> Hi Michael,
>
>
>