Re: Transport control API

My two cents ...

TCP slow-start algorithm makes the throughput to grow exponentially at the beginning. However, what makes the TCP  congestion-control-friendly is that it drops significantly the emission window in case of losses and, after that, the window grows only linearly. In [1] and [2] there are papers showing that UDP protocols not having such friendly behavior hurt significantly the performance competing TCP flows and may drive to instabilities in the network in case of congestion.

Conclusion: throughput ramp-up implementations should seriously consider congestion effects and react to them accordingly.

[1] http://users.cms.caltech.edu/~zliu2/gameFAST.pdf
[2] http://ladyr.es/assets/files/papers/llopez/jounalPapers/05_Lopez_TCS_tcp_tragedy.pdf

-----------------------------------------------------------
Luis López Fernández
Subdirector de Investigación y Relaciones con la Empresa
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Rey Juan Carlos
http://www.etsit.urjc.es
e-mail: luis.lopez@urjc.es
Tf: + 34 914 888 713

El 11/09/2013, a las 12:10, Markus.Isomaki@nokia.com escribió:

> 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.
>>> 
>>>> 
>>>> 
>>> 
>> 
> 
>