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

Re: setting bandwidth

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Sun, 28 Jul 2013 16:43:52 -0400
Message-ID: <51F58288.8010204@bbs.darktech.org>
To: Eric Rescorla <ekr@rtfm.com>
CC: Martin Thomson <martin.thomson@gmail.com>, Kiran Kumar <g.kiranreddy4u@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>

     Look, when I try to upload a very large file over TCP I see the 
upload speed peg at close to 100% of capacity seemingly immediately. 
Can't we take the same mechanism as TCP and layer it on top of what 
WebRTC uses today? I'd like to avoid drilling down into the specific 
implementation at this time. All, I'm asking is whether this is 
technically doable and if not, why.

     Let's not lose track of the goal of this discussion, which is to 
enable users to specify the initial/minimum bandwidth usage so chat 
sessions don't start out with blurry/choppy video at 1080p. If you have 
an alternative for achieving this, I'm all ears.

Thanks,
Gili

On 28/07/2013 3:58 PM, Eric Rescorla wrote:
> Websockets runs over TCP and so inherits TCP congestion control
>
> Ekr
>
> On Jul 28, 2013, at 21:52, cowwoc <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>
>>
>>     How do WebSockets deal with this problem? Do they even try to?
>>
>> Gili
>>
>> On 28/07/2013 1:10 PM, Martin Thomson wrote:
>>>
>>> This really isn't the place for lessons in congestion management on 
>>> the internet. Maybe you can start out by searching for "congestion 
>>> collapse". Get back to us when you can explain why TCP works like it 
>>> does.
>>>
>>> On Jul 28, 2013 5:06 PM, "cowwoc" <cowwoc@bbs.darktech.org 
>>> <mailto:cowwoc@bbs.darktech.org>> wrote:
>>>
>>>     On 28/07/2013 3:30 AM, Martin Thomson wrote:
>>>>     On 27 July 2013 09:40, cowwoc<cowwoc@bbs.darktech.org>  <mailto:cowwoc@bbs.darktech.org>  wrote:
>>>>>     I expect an immediate sharp video experience.
>>>>     I suspect that no matter what we do, you will be disappointed.  The
>>>>     thing is, what you describe is likely to generate congestion and there
>>>>     is no way that a browser platform should permit an application to do
>>>>     that.
>>>
>>>         I don't understand the congestion argument, so please help
>>>     me understand.
>>>
>>>         What will happen if we start at 3MBit, versus slowly
>>>     increasing bandwidth usage up to 3Mbit in the following cases?
>>>
>>>      1. The pipe is a synchronous 2MBit line
>>>      2. The pipe is a synchronous 4MBit line
>>>
>>>         For case #1, if the initial fence is minBandwidth = 3MBit, I
>>>     expect the callback to get invoked right away and it either
>>>     aborting the application or reducing the video resolution and
>>>     minimum bandwidth. In the case of a gradual ramp-up, I expect
>>>     the same end-result (callback getting invoked) but it will take
>>>     longer to occur and will take place at the 2MBit mark.
>>>         For case #2, I expect both scenarios (immediate vs ramp-up)
>>>     to be identical.
>>>
>>>         Did I miss anything?
>>>
>>>     Thanks,
>>>     Gili
>>>
>>
Received on Sunday, 28 July 2013 20:44:22 UTC

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