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 17:03:01 -0400
Message-ID: <5230DA85.6040408@bbs.darktech.org>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
CC: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Stefan,

     Duly noted, but I'm sure I'll have anything to add in this list. 
They seem to be discussing very low-level details and all I'm saying is 
that (at a high-level) our goal should be to ramp up much faster.

     Where do I request that WebRTC 1.0's goal should be to ramp up to 
1080p within (say) 10 seconds? I just want that noted somewhere, but I 
won't be the one to champion the actual technical details. I assume 
whoever is technically knowledgeable in this area can then bring up 
these requirements at IETF RMCAT and evaluate proposals.

Gili

On 11/09/2013 2:14 PM, Stefan Håkansson LK wrote:
> Hi,
>
> this discussion (i.e. the one about rate control) does not really belong
> here, I think IETF RMCAT is the right place for it.
>
> Stefan
>
> On 2013-09-11 12:14, Markus.Isomaki@nokia.com wrote:
>> Hi,
>>
>> cowwoc@bbs.darktech.org wrote:
>>> 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 understand you don't mean "3 seconds" literally, but I find that still a huge oversimplification. How HTTP/TCP download rates behave at the start-up depend at least on the number of TCP connections used, TCP's initial congestion window size (used to be 3 segments, now often more), and the RTT. 3 seconds contains a lot of RTTs on your LAN, but not so many between hosts on different continents.
>>
>>>        I hope we can all agree that it's unacceptable for it to be taking
>>> 1-5 minutes to reach the peak rate.
>> I agree that it should not need to take that long.
>>
>> Markus
>>
>>
>>> -----Original Message-----
>>> From: ext cowwoc [mailto:cowwoc@bbs.darktech.org]
>>> Sent: 11 September, 2013 08:44
>>> To: public-webrtc@w3.org
>>> Subject: Re: Transport control API
>>>
>>>
>>>        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).
>>>
>>> Gili
>>>
>>> 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 21:03:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC