Subject: [hybi] A case for more than 256 stream ids in multiplexing

From: Jamie Lokier <[email-masked]>
Date: Fri, 6 Aug 2010 03:06:49 +0100

(Please note I am not suggesting to make multiplexing mandatory
in the basic protocol.)

Several proposals suggest a single byte or so for stream ids in
a multiplexing extension.  I don't think 256 stream ids is a good
limit, in several scenarios:

   + User keeps open 50 tabs to their favourite sites, each of which is
     using Foo service.  Each page opens 10 WebSocket objects to the
     same site because it's now *cheaper*, due to transparent
     multiplexing, to create a few WebSocket objects than to go
     through hoops of writing cooperative code.

     =>  Browser --(highly multiplexed)-- Server

   + Lots of people visit sites A, B, C and D, all of which have their
     servers making use of a Web Service over WebSocket to
     handyservice.example.com.  handyservice is designed to be
     accessible from browsers directly (e.g. car traffic graphs), but
     the other sites found they can use it for their own rendering.
     Those sites each have 10^5 active users, and tend to keep open
     some large number of parallel conversations with handyservice,
     therefore they constantly have highly multiplexed connections to
     handyservice.

     =>  Backend Client --(highly multiplexed)-- Web Service

   + User opens 50 tabs to completely unrelated sites which aren't
     sharing anything, and the average number of WebSockets per site
     is > 5.  But user's web access is via a proxy.  All WebSockets go
     via the proxy, so they multiplex all on a single connection to
     the proxy, even though they are to different sites.

     =>  Browser --(highly multiplexed)-- Proxy --(not multiplexed)-- Server

   + A corporate site has a proxy (maybe "transparent", maybe not)
     that everyone uses for web access.  Lots of users access
     website.example.com, which opens a WebSocket for each user, via
     the proxy.  The proxy itself multiplexes different user's
     connections that all go to the same site.

     => Browser -- Proxy --(highly multiplexed)-- Server

That's pure numbers.  Now for a logical one:

   + The same corporate site has each user's browser opening
     multiplexed connections.  The proxy gets them and forwards them,
     combining them in some cases:

     => Browser --(little multiplexed)-- Proxy --(highly multiplexed)-- Server

     Now think about what happens when the browser adds another stream
     to its existing connection.  The proxy really ought to create
     another stream id on the existing connection to the server,
     especially when it relates to an existing connection from the
     browser, but if there's a reachable limit, it won't be able to.

It is clearly possible to just open more connections when the stream
id limit is reached.  That's an option.  But it would be trivial to
avoid making it an issue by allowing a large range for stream ids.

Implementation experience will reveal what sort of range to actually
use in practice, and when to use multiple TCPs.

There's an arguable case against lots of stream ids in a single TCP
connection, which is that lots of streams involves so much data that
forcing it over multiple connections wouldn't add overhead.  This
argument is false: Many conceivable applications will involve
nearly-always-idle WebSockets, as well as WebSockets which carry
occasional very short messages (such as a single byte telling the page
which part to refresh).  Those applications would not transmit much
data even in aggregate of >256, and then the keepalive bandwidth and
(mobile) power savings remain significant.

The last example above, the logical one where you need "one more
stream than currently in use" due to a new stream coming on an
existing connection, suggests a limit (that is practically reachable)
could trip up an implementation in some cases.

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 6 Aug 2010 12:25:29 +1000

Jamie,

It can also simplify stream handling if the IDs are monotonically
increasing and that if a stream is closed it is never (or at least not
for a long time) opened again.

8 bit stream ID would be workable, but more would be better.

cheers

On 6 August 2010 12:06, Jamie Lokier <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>