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

[Roberto Peon <[e-mail]>]

imho, we're reinventing SPDY/HTTP/2, and I'd rather implement the
complexity of muxing, security, prioritization, flow-control,
liveness-checking, stream initiation, and compression, only once.
-=R


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

> > 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
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>