Re: [hybi] Requirement: extensions and sub protocols

[Jamie Lokier <[e-mail]>]

KOMATSU Kensaku wrote:
> > Can you say a bit more about the circumstances when an endpoint would
> > choose to use them instead of multiplexing?  What kind of parameter values
> > are needed for multiple TCPs to be better?
> >
> > I have not heard of this before, although I appreciate that multiple
> > TCPs can be faster than a single shared TCP in some scenarios.  (I'm
> > thinking of bonded-ADSL where each TCP is confined to exactly one of
> > the links).
> >
> > Sometimes 4 TCPs is better than 1, but worse than 100, when you have
> > 100 individual flows to transport.  But I'm not sure how to decide
> > what to use automatically.
> 
> Per TCP connection transmission rate is calculated by the formula below.
>  <rate> [Mbps] = 65535 / (125 * RTT[msec] )
> (I also assumed that TCP receive buffer size = 64KB (winXP's default value))
> This formula is reasonable, in my experience, because either the
> theory value or the actual measurement value are not so different.
> 
> For example.
> RTT : 10msec ... 52Mbps
> RTT : 15msec ... 35Mbps
> RTT : 50msec ... 10Mbps
> RTT : 100msec ... 5Mbps
> 
> So, if someone wants to provide their service with transmission rate
> = 10Mbps, 1 tcp connection is enough for RTT < 50msec users. Though,
> 2 or 3 connection is required for RTT=100msec users.

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.

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

-- Jamie