Re: [hybi] Flow control quota

[Takeshi Yoshino <[e-mail]>]

On Wed, Jun 13, 2012 at 9:17 PM, Arman Djusupov <[e-mail]> wrote:

> But by doing so we dodge the problem with non fragmentable frames that
> might
> be produced by any future extension that is unknown to the intermediary.
> For
> example we may need a reliable streaming extension that numbers all the
> frames and adds the frame number in the extension data so that it can
> resume
> sending the message if the connection fails. Such an extension would not
>

This implies that frame boundary is preserved end-to-end (or we may say
it's preserved extension-to-extension).

Some extensions may just require per-message signaling. Some may require
signaling not aligned to message boundary. Your example might be in the
latter group. Boundaries each extension want to place and use may differ.
Now I think that sharing WebSocket fragmentation defined in RFC 6455
between such extensions is not realistic. But we do have it. For what we
can utilize it?
- partial flush
or
- partial flush and multiplexing

Regardless if we use fragmentation for mux or not, I'd suggest that we stop
using the frame boundary signal for compression, and refrain from using the
boundary of fragmentation and RSV bits and extension data field as
per-frame (per-processing-unit) signaling for future extensions, too.

Extension data is not the only place extensions may touch. Extensions may
transform application data. Per-frame compression does it. No worry.
"reliable streaming extension" may embed sequence and the size of the chunk
in application data. We tend to miss the frame boundary information, but
let's accept new overhead for extensions to represent their processing unit.


> support fragmentation so it would set the RSV bit of each frame to prevent
> it from being fragmented by intermediaries. As long as the parent
> specification allows extensions to place their data at the beginning of the
> frame payload, this extension's data would not be recoverable if the frame
> is fragmented, so such an extensions would be incompatible with mux.
>

> It's ok if some extensions are not compatible with mux intermediaries,
> since
> the WebSocket specification allows intermediaries to refuse extensions that
> are not known to them. But ideally mux should be transparent to all
> extensions, so that mux intermediaries can be unobtrusively introduced at
> any point of the communication path without placing any restrictions on the
> extensions that may be used and the type of payload being exchanged.
>

The ideal mux does require encapsulation (#2). As John said, it was hard to
sell. Maybe, we can call for opinions again.

I'm ok with full encapsulation though I doubt refragmentability (without
parsing mux) after mux is really important.


>
> So I think we should take a bit more time to think on how we can resolve
> the
> problem with mux without changing per-frame compression. The second problem
> is that changing per-frame compression so that it is applied on the message
> boundaries would create an issue if it is applied after mux. Since after
> mux
> there are no message boundaries any more as message frames are intermixed,
> the compression would have to be applied on each frame separately. So
>
effectively per-frame compression extensions would have two modes of
> operation, which would be very hard to define in a specification. It would
> practically make it a requirement that this per-frame compression extension
> be aware that mux is being used. IMO having such coupling between
> extensions
> would be a bad design.
>

Hmm...