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

Re: Transport control API

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 11 Sep 2013 18:14:45 +0000
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>
CC: "cowwoc@bbs.darktech.org" <cowwoc@bbs.darktech.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C390A71@ESESSMB209.ericsson.se>
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 18:15:10 UTC

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