Websockets runs over TCP and so inherits TCP congestion control Ekr On Jul 28, 2013, at 21:52, cowwoc <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> wrote: >>> On 28/07/2013 3:30 AM, Martin Thomson wrote: >>>> On 27 July 2013 09:40, cowwoc <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? >>> The pipe is a synchronous 2MBit line >>> 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 19:58:44 UTC