Re: Transport control API

On 2013-09-11 23:03, cowwoc wrote:
> 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.

I think you should forward this to the RMCAT group. There is a 
requirement document developed by that group [1], and it in fact brings 
up initial ramp up in requirement 10, but I'm sure they would welcome 
more input.

[1] http://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/
>
> 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 Thursday, 12 September 2013 07:14:34 UTC