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

[Tobias Oberstein <[e-mail]>]

> On Mon, May 27, 2013 at 10:25 AM, Takeshi Yoshino <[e-mail]>
> wrote:
> > Isn't it in-app priority? Can't script and server address that
> > problem? If only the client knows current priority, the client can
> > tell the priority to the peer servlet using a WebSocket message. If
> > the server know priority for each position, it can just control transmission
> speed.
> >
> > Even if we need help by the server, the servlet would call some
> > special function to tell the server about priority.
> >
> > Different from HTTP/2.0's case, we don't need to provide a special
> > field in mux protocol to pass priority, I think.

If intermediaries are no preserve a per-channel priority based scheduling, then they might need to know the channel priority.

> 
> Sure, but then you force every application to reinvent this mechanism on top of
> WebSocket mux.
> At that point, one could argue that application messages could have their own
> "channel_id" in their messages, and applications can do mux themselves, if
> they need it.

Yep, agree.

Scheduling integrated with MUX has another advantage:

e.g. when doing per-channel priority based scheduling the scheduling could not only consider channel priority, but also the quota.

A high priority channel with data outstanding to be sent but not quota to send would otherwise block a lower priority channel with data _and_ quota.

Another issue: implementing s.th. like priority based scheduling at app level would might require to reinvent some kind of fragmentation at the app level to be able to schedule according to priority (otherwise once a very large message on a low prio channel is started to be sent, it'll block everything else).

One way to look at this is:

WS fragmentation < WS multiplexing < WS scheduling | APP

where "<" means "builds on", and everything up to "|" is provided by an WS implementation, hence does not need to be reinvented at app level, and WS aware infrastructure can optimize / do their thing.

===

It seems that HTTP/2 likely will have "request priorization" (I don't know about "response priorization").

If we (in a pure WS land) don't have priorization, that's a potential disadvantage and source of discussion.

===

A per-channel scheduling could work according to different policies:

1. Round-Robin scheduling
2. Priority scheduling
3. Fair Bandwidth scheduling
4. First-Come, First-Serve scheduling

The policy mechnism could be selected for the whole physical WS (and communicated for intermediaries), e.g.

Sec-WebSocket-Extensions: mux; scheduler="round-robin"

Only with 2. there is a need to select and communicate a per-channel info (during channel creation), e.g.

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

and then

AddChannelRequest with the 3 RSV bits (currently unassigned) containing a priority 0-7 for the channel. 

[This does not yet answer how to re-prioritize an existing channel]

Hence I'd like to propose to

1) add an (optional) extension parameter "scheduler" as above
2) use the 3 currently unassigned RSV bits in AddChannelRequest for channel prio (when scheduler="priority")
3) define appropriate MUST semantics (scheduling should not follow advisory semantics .. apps should be able to rely on it)
4) probably add a new PriorityControl message to change prio of existing channels

===

Above is a kind of per-channel scheduling. One might argue that it lacks in at least 2 respects:

- an app is not able to control e.g. prio on a per-message basis
- there are no ordering guarantees between messages on different channels

Example:
An app creates an empty file on some cloud service. Subsequently the app wants to append to that file.

The first could be a high-prio message, the latter messages low-prio.

The app does not care whether those messages travel over 1 physical, or multiple different logical WS channels.

However, the app does care that the first "create file" message arrives before any subsequent "append to file" messages.

So a different design involving per-message prios on a single WS channel (physical or logical) might allow higher-prio messages to overtake lower prio-messages, but not otherwise round. 

/Tobias