Re: [rmcat] Priority and rtcweb

Harald Alvestrand <harald@alvestrand.no> Wed, 15 November 2017 05:41 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017441294B3 for <rmcat@ietfa.amsl.com>; Tue, 14 Nov 2017 21:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkXibCbFZjJw for <rmcat@ietfa.amsl.com>; Tue, 14 Nov 2017 21:41:13 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25D51292AE for <rmcat@ietf.org>; Tue, 14 Nov 2017 21:41:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C932C7C3552 for <rmcat@ietf.org>; Wed, 15 Nov 2017 06:41:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40gvJEcwEkKl for <rmcat@ietf.org>; Wed, 15 Nov 2017 06:41:08 +0100 (CET)
Received: from [IPv6:2001:67c:370:128:d17c:7d46:9cc9:b1a4] (unknown [IPv6:2001:67c:370:128:d17c:7d46:9cc9:b1a4]) by mork.alvestrand.no (Postfix) with ESMTPSA id DFB4E7C0166 for <rmcat@ietf.org>; Wed, 15 Nov 2017 06:41:07 +0100 (CET)
To: rmcat@ietf.org
References: <CACHXSv7z3KSNB+4PZ9+AgrW1nzc7ZH2fbNbBDoeKVqm=SYmZuQ@mail.gmail.com> <B01370E2-AABE-41D4-A7A7-8A062ED3B42B@ifi.uio.no>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <5e771d80-acd7-b18a-b00f-6e9bd252cb6c@alvestrand.no>
Date: Wed, 15 Nov 2017 06:41:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <B01370E2-AABE-41D4-A7A7-8A062ED3B42B@ifi.uio.no>
Content-Type: multipart/alternative; boundary="------------458379A6243DE3C4B6383284"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/9TCeQlSCcaG3rRWUxxgfBC8HrxQ>
Subject: Re: [rmcat] Priority and rtcweb
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 05:41:15 -0000

On 11/13/2017 09:44 AM, Michael Welzl wrote:
> 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?

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.




>
> Cheers,
> Michael
>
>
>> On Nov 13, 2017, at 2:41 PM, Varun Singh <varun@callstats.io
>> <mailto:varun@callstats.io>> 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. 
>>
>> 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://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/>
>

-- 
Surveillance is pervasive. Go Dark.