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

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 25 Jun 2012 17:46:03 +0900

Recently some issue with integration between compression and multiplexing
was pointed out on the list.

See this thread:
http://www6.ietf.org/mail-archive/web/hybi/current/msg09679.html

In summary,

a) current per-frame compression locks down fragmentation since it flips
RSV1 for each frame and it requires frame boundary unchanged to apply
decompression algorithm correctly
b) multiplexing needs to have control over fragmentation to flush data
within given send quota and to give time slots fairly

a) and b) conflicts when compression is used before multiplexing (i.e.
applying compression for each logical channel separately)

Ad-hoc solutions would lead to dead locking, bad implementation,
interoperability issue. We need clear and simple one.

One solution is to change the compression to per-message basis (flip the
RSV1 bit only on the first fragment. SYNC_FLUSH at the end of message). But
then, the changed compression cannot be applied to the stream after
multiplexing. So, then we need two different compressions (current one and
changed one) for use before mux and after mux.

Another approach is encapsulating multiplexed frames. This idea got lots of
objection due to it's extra overhead when the base framing was discussed.
Taking into account the issue, and possible layering problems in the
future, how about revisiting multiplex layering now?

Issues with encapsulation
- extra overhead
- channel ID will be included to compression target
...

Takeshi