Re: [hybi] permessage-priority extension draft

This part contains a contradiction:

Intermediaries unaware of the permessage-priority extension

      1. MUST NOT change the message fragmentation (further fragment or
      coalesce non-control frames)

      2. MUST preserve strict frame order while processing and
      forwarding non-control frames

      3. MUST ignore WebSocket base protocol rules as they apply to
      continuation frames and the FIN bit

   or

      1. MUST remove the "permessage-priority" element from the client's
      "Sec-WebSocket-Extensions" header in the opening handshake

If the intermediary is unaware of the extension, then there is no way for
it to follow the rules in extension specification.

I think we can extrapolate a more general "all or nothing" rule from this.
A WebSocket intermediary must either treat all data as opaque and pass it
through unchanged, or completely implement the specification and all
extensions in use.

It follows that a WebSocket intermediary that understands the protocol must
strip any unrecognised extensions from the client handshake.

Thinking about compatibility with permessage-deflate, I came to the
conclusion that RFC6455 is too optimistic about extension compatibility.
The default expectation should be that extensions are incompatible, and the
WebSocket Extension Name Registery should have a list of "Known Compatible
Extensions" rather than "Known Incompatible Extensions".

As an implementer, my personal preference would be to not implement
permessage-priority. It requires changes in almost every layer of the
stack, adding complexity and overhead. I see my job as to get bytes from
the Javascript send() call into the kernel send buffer as efficiently as
reasonably possible; ideally I would like to avoid any additional queuing
altogether, never mind re-ordering of queued messages.

Thanks,
Adam Rice

On 18 January 2014 08:10, Tobias Oberstein <tobias.oberstein@tavendo.de>wrote:

> There is a collection of open issues here:
> https://github.com/oberstet/permessage-priority/issues
>
> One of those is how to make permessage-priority compatible with
> permessage-deflate.
>
> I guess it can be done by maintaining a separate compression context per
> priority class.
> This allows intermediaries to prioritize and reorder frames without
> problems. However,
> it multiplies memory requirements.
>
> Was there any discussion/plan about how permessage-deflate would have
> worked with MUX
> when compression was applied to the physical WebSocket connection?
>
> I mean, when compression was applied to the logical MUXed WS connections,
> there
> would have been a separate compression context for each (logical) WS
> connection also,
> and intermediaries can reMUX without recompressing.
>
> But when applied to the physical WS?
>
> /Tobias
>
> > -----Ursprüngliche Nachricht-----
> > Von: hybi [mailto:hybi-bounces@ietf.org] Im Auftrag von Tobias Oberstein
> > Gesendet: Donnerstag, 16. Januar 2014 17:39
> > An: hybi@ietf.org
> > Betreff: [hybi] permessage-priority extension draft
> >
> > Alright, I have written up a draft for a "permessage-priority" WebSocket
> > extension:
> >
> >
> https://github.com/oberstet/permessage-priority/blob/master/draft-oberstein-
> > hybi-permessage-priority.txt
> >
> > In writing this, I came to the conclusion that "message prioritization"
> on a
> > single WebSocket connection in fact is orthogonal to multiplexing
> multiple
> > (logical) WebSocket connections over a single physical one (be it via
> WS-MUX
> > or a variant of WS/SPDY).
> >
> > So this proposal should not be seen as a competitive proposal to WS-MUX
> or
> > WS/SPDY, but as ... something different;)
> >
> > The motivation and use case is outlined in the introduction.
> >
> > I'd appreciate any feedback, suggestions, corrections or even PRs (the
> draft is
> > on GitHub in a dedicated repo).
> >
> > If the draft doesn't conform to RFC requirements or formatting rules,
> please
> > forgive - this is my first RFC.
> >
> > Cheers,
> > /Tobias
> >
> > PS: For one thing I don't know, how do I submit this draft with the IETF
> so it can
> > follow the proper way?
> >
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>