Re: [hybi] Requirement: extensions and sub protocols

[KOMATSU Kensaku <[e-mail]>]

2010/3/6 Jamie Lokier <[e-mail]>:
> KOMATSU Kensaku wrote:
> That was true a few years ago, but things have changed.
>
> I believe Windows later than XP, i.e. Vista and Windows 7, now
> automatically enlarge the receive window according to heuristic
> measurements.
>
> Current Linux also does the same thing.  It will set the receive
> window up to 3.4Mbyte on my laptop, for example, if it thinks the path
> needs that much for throughput.
>
> It is for exactly the reason you've described: the old 64k window
> limit was too small to get good throughput on 10Mbps links with 50ms
> latency, which are getting common.
>
> For that reason, there's no benefit to having several parallel TCPs
> any more on that sort of link, on current OSes.
>
> However your point still applies to WebSocket usage on older OSes, and
> it may be necessary to use multiple TCPs based on RTT and window size
> measurements to get the full throughput on them.
>
> It's a good reason for applications to be able to flag some WebSockets
> as "should not be combined with others".  Since there are proxies in
> development which automatically combine multiple WebSocket
> connections passing through them, it probably should have a way to be
> signalled in the handshake, too.
>
> Then again, wouldn't it be even better to multiplex everything
> together, and then have a multi-TCP protocol to carry the whole
> together when beneficial, so that even one application WebSocket could
> get the full link bandwidth?
>
>> I also agree with multiple connections are confortable for web
>> application developer,
>> because it offeres an appropriate speed in most cases without
>> bothersome control.
>> But this manner requires more connection resources than necessary.
>>
>> Number of TCP connection affects to connection-sensitive equipment,
>> global-NAT, proxy, firewall,load-balancer, servers, .... If we use
>> appropriate number of connection and multiplexing frames for web
>> applications, the system cost can be made low-priced. And I hope that
>> this senario will also pleased network providers.
>> To achieve this senario, preparing some libraries, defining
>> sub-protocol or extentions and making it easier to use will be
>> important. That's why I mentioned this-topic before.
>
> Exactly, I agree with all of that.
>
> But I think having the WebSocket implementations automatically choose
> a number of TCP connections based on dynamic RTT measurement (which
> will vary for different destinations, and vary over time) and the
> negotiated window size might be simply too difficult.
>
> I think it's better to use OSes which extend the window size
> dynamically - they are in a much better position to make the right
> measurements, and also to take into account memory used.  It's much
> simpler that way too.

Thanks a lot!!. I agree with your comment, so I'll choose multiple frames in one
TCP connection in current OSes. I'm sorry my lack of survey.

And, I'll keep challenge automatically choose # of TCP connections based on
RTT measurement for OLD OSes(those don't support above features). Yes, I
know this is hard challenge, but I can't disregard those share.

>> For other case, It'll be useful for video service. Because it'll be
>> useful for the decision of the bandwidth of contents automatically.
>
> I don't understand that.  To determine bandwidth, something has to
> measure the bandwidth.  Counting connections won't do that.  Can you
> explain a bit more how you think it will help video delivery?

Sorry for mis-wording... I meant content's bit rate.

It is based on my old experience... About 7 years before, I served
hi-vision video
services via http/rtsp-tcp streaming. 6Mbps contents worked well when
RTT was small,
but I found that video service(30fps) fall down to picture story(2 or
5 fps) when RTT got
larger. But in those situation, 3Mbps contents was fine(due to tcp
flow control). So,
automatically choose contents-bit rate based on RTT measurement was useful.

But, with your comment, I understand above story is old one.

Sincerly
---
Kensaku KOMATSU