- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Sun, 28 Jul 2013 16:43:52 -0400
- 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>
- Message-ID: <51F58288.8010204@bbs.darktech.org>
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