W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2013

Re: Transport control API

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Wed, 11 Sep 2013 01:43:48 -0400
Message-ID: <52300314.6000309@bbs.darktech.org>
To: public-webrtc@w3.org

     One thing I would like to discuss (unfortunately we ran out of time 
during the call) is whether there is consensus that the current WebRTC 
implementations should ramp up faster.

     One issue that is consistently brought to bear against the idea of 
minimum bandwidth is network congestion/safety. I'd like to bring the 
following to your attention: if you download a large file from DropBox, 
HTTP will ramp up to the peak download rate within 3 seconds. I don't 
really need/want a "minimum bandwidth". What I really want is WebRTC to 
ramp up within 3 seconds.

     I hope we can all agree that it's unacceptable for it to be taking 
1-5 minutes to reach the peak rate.

(In truth, I'd still want min/maxBandwidth fence conditions -- as 
notifications, not hints to the browser -- simply so the application can 
scale video resolution up/down depending on whether it can afford 
more/less usage).


On 05/09/2013 8:01 AM, Stefan Håkansson LK wrote:
> On 2013-09-05 13:53, Harald Alvestrand wrote:
>> On 09/05/2013 09:41 AM, Stefan Håkansson LK wrote:
>>> Hi all,
>>> I've updated the WiKi page [1] based on what I heard at the teleconf
>>> September 3rd. Feedback and comments are appreciated.
>>> Note that I'm not claiming this represents consensus, or that I
>>> correctly understood what people meant at the call. I'm just trying to
>>> move the discussion forward.
>>> Stefan
>>> [1] www.w3.org/2011/04/webrtc/wiki/Transport_Control
>> I added a few contributions.
> Thanks. Seems we took away more or less the same from the teleconf.
>> Remember that this is a wiki - anyone can write on it. (all changes are logged, of course).
> Of course.
Received on Wednesday, 11 September 2013 05:44:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC