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

[Roberto Peon <[e-mail]>]

Noone is unbiased, but I'm a lot less biased than you'd think given my name
is within the WS doc too and I was pretty active in attempting (and sadly
failing) to get mux into the base WS functionality. :)

Out of curiosity, and on a different topic, how large have the messages
been in your applications?
-=R


On Mon, Jun 3, 2013 at 2:33 PM, Tobias Oberstein <
[e-mail]> wrote:

> >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
>
> First, lets admit: we are both biased;)
>
> What about HTTP/2 over WS?
>
> http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-02
>
> I prefer native WS. I do single-page web apps with app manifests.
>
> The attractiveness of SPDY(TM) (be it native or over WS) in this situation
> is limited. Any static resources are retrieved only once anyway, and any
> communication after that can be done via WS.
>
> - native WS is widely implemented today
> - native WS has lower per-message overhead than "WS over SPDY(TM)"
> - WS (now) has _payload_ compression
> - liveness checking => WS pings/pongs
> - security => WS masking, WS origin
>
> So I'd say a WS-MUX with flow-control (draft there) plus
> priorization/scheduling (not there) is "the last missing piece". Lets
> finish it.
>
> /Tobias
>
>
> 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
>
>