Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

[Tobias Oberstein <[e-mail]>]

Am 10.06.2013 09:12, schrieb Adam Rice:> I believe our priority is to finalise a multiplexing specification 
> quickly. So we should focus on what is essential for multiplexing to be 
> useful.

I agree.

I'd like to note however that "useful" from my POV depends on use-case. 

Reducing the number of physical TCPs in scenarios like

1. multiple web apps of a single vendor open in multiple browser tabs
2. web widget from a vendor embedded into pages of many sites

might already be well addressed with MUX+flow-control and don't necessarily need priorization.

Scenarios like e.g.

3. single app with multiple communication requirements with different  TOS (low-latency/mass..)

might need MUX+flow-control+priorization.

> I think we have general consensus that flow control is essential.

Yep, seems nobody stepped up for multiplexing _without_ flow control.

> I have not been convinced that prioritisation is essential. In the event 

It's not essential for use case 1. + 2. above, I agree. But it is for use case 3.

> for different traffic types. To make this easier to deploy, I am leaning 
> towards the idea that wss://a.example.com/ <http://a.example.com/> and 
> wss://b.example.com/ <http://b.example.com/> should be considered 
> distinct endpoints, even if the IP address is the same.

+1 for making those "different" (cannot be mux'ed over same physical WS).

> I am not saying that prioritisation is not desirable, just that I don't 
> think the complexity versus benefit tradeoff makes sense right now.

Ok. I agree that specifying different scheduling schemes etc in detail now
would delay the draft.

However, even the current draft contains text

"""
13. Fairness

Sender side

   o  The sender MUST use a fair mechanism for selecting which logical
      channel's data to send in the next WebSocket message.  Simple
      implementations may choose a round-robin scheduler, while more
      advanced implementations may adjust priority based on the amount
      or frequency of data sent by each logical channel.
"""

Here is an idea: could we just include minimal additions which would allow
describing specific scheduling algorithms later or in separate documents?

Like e.g. the "permessage-compression" draft does: it provides a _framework_
for compression schemes, and only specs 1 algo: deflate.


Here is a proposal that only adds to the opening handshake on physical and logical WS:

************************

1) Handshake on physical WS

Example 1.1

client-to-server: "mux; scheduler=roundrobin"

=> client announces MUX, and states that it implements only "roundrobin" scheduler.

server-to-client: "mux; scheduler=roundrobin"

=> server agrees to speak MUX and round-robin scheduling

Only "roundrobin" would be described in the current draft.

Example 1.2

client-to-server: "mux; scheduler=priority, mux; scheduler=roundrobin"

=> client annouces MUX, preferring "priority" based scheduler, but may fallback to roundrobin

server-to-client: "mux; scheduler=priority"

=> server agrees to speak MUX and select priority-based scheduling

Detailing "priority" scheduling would be postponed.


2) Handshake on logical WS

For a future priority scheduler, a client should be able to _hint_ which priority
a new (logical) WS connections should have.

The only way to do that without changing the WS (browser) API would be
to include the "hint" within the WS URL opened by the client:

Example 2.1

URL 1 : ws://example.com/chat
URL 2 : ws://example.com/file

Example 2.2

URL 1 : ws://example.com?priority=7
URL 2 : ws://example.com?priority=1

A server receiving such a new logical WS connection may then respect the hint,
and send back header in logical handshake:

Sec-WebSocket-Extensions: mux; scheduler=priority; priority=7

if the scheduler is "priority" on the physical WS. Otherwise it ignores the hint.

The client then applies the parameters sent by the server in the logical handshake to
the scheduler for the physical WS.

************************

In effect, the scheduling scheme in use is negotiated during the opening handshake on 
the physical WS, while the per-channel scheduler parameters can be hinted by the client,
but are always (finally) decided by server (for both client and server side) and determined
during the opening handshake on the logical WS for the channel.

Pros:

+ only uses WS extensions headers of physical and logical WS
+ no additional MUX control frame opcodes
+ no use of MUX control frame RSV bits
+ no browser API change

Cons:

- scheduler parameters for logical WS cannot be changed dynamically
- TOS parameters cannot be chosen "per WS message"


I think with a little more work we could prepare for more advanced scheduling
schemes in the future and allow implementations to experiment today without
breaking interoperability.

/Tobias