Subject: [hybi] Replacing encapsulation method of the mux extension with END_SEGMENT (was: Re: Discontinuation of mux ...)

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 7 Feb 2014 21:07:31 +0900

Just FYI, here's how the WebSocket specific mux extension (which we were
developing in HyBi) would be like if its encapsulation method is replaced
with HTTP/2.0 DATA frames and END_SEGMENT (formerly MSG_DONE) signal.

If the WebSocket header fields are represented as HEADERS HTTP/2.0 frame,
it'll be the same as yhirano's plan C.

====

Data frame 1
- 1bit: FIN of the encapsulated WebSocket frame
- 3bits: RSV1-3 of ...
- 4bits: Opcode of ...
- Rest: 1st part of payload of ...

Data frame 2
- 2nd part of payload of ...

...

Data frame N (with END_SEGMENT set)
- Last part of payload of ...

====

See also http://www.ietf.org/mail-archive/web/hybi/current/msg10404.htmlfor
the reason why I think it's fine to exclude frame length.

On Fri, Feb 7, 2014 at 4:23 AM, Roberto Peon <[email-masked]> wrote:

>
>
>
> On Thu, Feb 6, 2014 at 7:26 AM, Peter Thorson <[email-masked]>wrote:
>
>>
>> I am fine with a “flush hint” flag where the sending endpoint
>> *may/should* add it to HTTP/2.0 frames that the application prefers not to
>> have buffered/delayed by intermediaries. I am fine with a separate bit
>> named FLUSH_HINT (useful for either Plan D or native messaging) or re-using
>> MSG_DONE to imply “flush hint” for Plan D streams if MSG_DONE is used
>> elsewhere by HTTP/2.0. I would not want to define specific scenarios where
>> a flush must occur.
>>
>
>
> HTTP2's MSG_DONE (under a different name) is in the next implementation
> draft, coming out shortly.
> For HTTP on HTTP/2 it is use for delimiting chunk boundaries on an HTTP
> stream, since the lack of this has proven painful for some. Intermediaries
> are disallowed from coalescing data across frame where this is set.
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 25 Feb 2014 02:03:17 +0900

draft-ietf-hybi-websocket-multiplexing-11 (mux extension) encapsulates NOT
frames but segments of the original WebSocket message into a series of
encapsulating WebSocket messages. So,
- The mux extension changes fragmentation of a message as it wants, so
frame boundary in the original traffic is NOT guaranteed to be preserved.
- The mux extension CAN transport interjected control frames in the
original traffic.

That's the choice we made and had in -11.