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

[Takeshi Yoshino <[e-mail]>]

On Sat, Jun 1, 2013 at 6:55 PM, Tobias Oberstein <
[e-mail]> wrote:

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

Good point.


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

Yes, if the algorithm is designed to do so.


> 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).
>
>
Yes. The app must be able to send a fragment.

But it's a matter of WebSocket API. A server can do that, but if a client
want to, it can't for now due to limitation of the API. Hence, it needs
application level fragmentation.


> 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.
>
>
Yes


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

WebSocket API is not ready for such a sophisticated ToS mechanism.


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

I think it's ok.


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

I see.