Subject: Re: [hybi] Call for opinions on multiplexing (separate layer for multiplexing, again)

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 3 Jul 2012 14:40:52 +0900

Hi,

I got some support on the thread discussing this issue, so I'm going to
make some change on both compression extension and multiplexing extension.

This approach sweeps away most of concerns (intermediary, future extension,
mux-compress integration, etc.) by 1 octet/frame additional overhead for
mux and sacrificing per-frame signaling (any extension flipping bit or
placing different extension data for each frame. any extension expecting
frame boundary to be preserved between endpoints).

The role of fragmentation will be limited to transporting a big message
being split into smaller chunks and interleaved with other channels' data,
control frames. Nothing else will be carried by fragmentation.

=== Compression ===

algorithm
- per-frame -> per-message
-- RSV1 bit is set on the first fragment of compressed message. Not for
each frame
-- strip 4 octet at the end of the message. Not for each frame
- compress only Application data -> compress payload

pros
- doesn't lock fragment. non-compression-aware intermediaries can safely
re-fragment
- no need to send feedback from multiplexing processing module to
compression module to adjust fragment size to fit flow-control quota

cons
- original frame boundary is not guaranteed to be preserved
- compressed data for one byte in the original frame may be split into two
frames
- since non-compression-aware intermediaries can re-fragment, endpoints
cannot use per-frame signaling safely

=== Multiplexing ===

algorithm
- adjusts fragment according to quota
- then, encapsulates each frame into a binary message
-- frame (after adjustment) and encapsulating message correspond 1-to-1
-- strip (extended) payload length, mask bit and masking-key from the
original frame
- puts the channel ID data at the head of the encapsulating message

pros
- output frame sequence is not interleaved
-- per-message compression can be used before/after multiplexing
- non-multiplexing-capable intermediaries can safely
-- re-fragment
-- insert Ping/Pong/Close

cons
- original frame boundary is not guaranteed to be preserved
- cannot be applied after any extension that uses per-frame signal
- 1 byte additional overhead compared to
draft-ietf-hybi-websocket-multiplexing-02

---

From: Martin Sustrik <[email-masked]>
Date: Tue, 03 Jul 2012 10:08:26 +0200

> - puts the channel ID data at the head of the encapsulating message

+1

Martin

---

From: "Arman Djusupov" <[email-masked]>
Date: Tue, 3 Jul 2012 13:49:40 +0300

+1, this is in tune with the changes I wished to be made to the spec.

With best regards,

Arman

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Tuesday, July 03, 2012 8:41 AM
To: [email-masked]
Subject: Re: [hybi] Call for opinions on multiplexing (separate layer for
multiplexing, again)

Hi,

I got some support on the thread discussing this issue, so I'm going to make
some change on both compression extension and multiplexing extension.

This approach sweeps away most of concerns (intermediary, future extension,
mux-compress integration, etc.) by 1 octet/frame additional overhead for mux
and sacrificing per-frame signaling (any extension flipping bit or placing
different extension data for each frame. any extension expecting frame
boundary to be preserved between endpoints).

=== Compression ===

algorithm

-- RSV1 bit is set on the first fragment of compressed message. Not for each
frame

pros

cons

=== Multiplexing ===

algorithm

pros

-- re-fragment

cons

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 4 Jul 2012 17:37:58 +0900

FYI, we can make a bit more optimization.

Adopting a part of Tobias's idea in this mail
http://www.ietf.org/mail-archive/web/hybi/current/msg08230.html (actually,
the base idea we took was already proposed by him in this mail. I just
realized...), we may allocate mux FIN bit on RSV2 to eliminate the first
octet for original frames that are not first fragment.

In the new draft, we disallow mux to be layered below any extension that
uses per-frame signal. So, only RSV1, 2, 3 on the first fragment are
meaningful. That's why we need to have only mux-FIN information on
encapsulating messages for non first fragments.