Message Multiplexing (memux) Charter
Name | Area |
| Directors |
| Description | Goals &
Milestones | Background
Working Group Name
Message Multiplexing (memux)
Transport Area Directors
Responsible Area Director
(NOT EXTANT YET; use email@example.com until then) mailing list and
are available for discussions of MEMUX. Postings to this mailing list from
non-subscribers are moderated in order to avoid spam, everything else will
be passed as is. See the Mailing list administrativia
Description of Working Group
The goal of this working group is to develop a lightweight protocol that
delivers multiplexed bidirectional reliable ordered message streams over
a bidirectional reliable ordered byte stream protocol (such as TCP).
This is envisioned as a relatively small, low-level piece of other protocol
stacks, fitting between, e.g., TCP and RPC. The length of a message
is unrestricted (e.g., not bounded by layer 2 or 3 packet sizes), and the
payload of a message is also unrestricted; such a message can be used directly,
e.g., as a request or a response in an application-level request/response
protocol. Within each message stream, the messages are delivered
reliably and in order (as are bytes in TCP). Each message may be
passed as a series of chunks, so that the multiplexing does not introduce
unnecessary synchronization between streams. The MEMUX protocol will
be layered on top of bidirectional reliable ordered byte stream protocols
(such as, but not limited to, TCP), and multiplex many message streams
over a single byte stream connection. It should be possible to put
multiple message chunks into one IP packet. The MEMUX protocol will
be lightweight in these two ways: (1) its overhead, in bytes on the wire,
will be low, and (2) opening and closing new message streams, once the
byte stream connection is established, will take few bytes and impose no
round-trip delays. The value of the MEMUX protocol is twofold: (1)
it provides a commonly useful service abstraction (bidirectional reliable
ordered arbitrary-sized message stream), and (2) the multiplexing achieves
the same results as state sharing between parallel TCP streams (which is
not widely available today). The second value may cease to be unique
in the future (when TCP and/or replacements that effectively share state
between parallel connections become widely available), but having built
other protocols and implementations on top of the service provided by MEMUX
enables a smooth transition to a MEMUX-- that delivers the same service
while doing no multiplexing of its own.
MEMUX will be designed with security in mind, even though MEMUX's job
is not to add security enhancements to protocol stacks. That is,
the "heavy lifting" of implementing security enhancements such as authentication,
integrity, privacy, authorization, etc. are to be done in other protocol
layers (above and/or below MEMUX); examples include: TLS below, something
GSS-based above. It should be possible to include MEMUX in a protocol
stack that does have real security without MEMUX losing the security gained
by the other layers. The WG will consider the issues of security
problems introduced by the MEMUX layer itself. Firewall issues will
An Informational RFC on the goals of the MEMUX protocol.
Standards-track specification of the MEMUX protocol.
Out of Scope
Replacing TCP; MEMUX is to be layered over TCP, not replace it.
Underlying connection agility; MEMUX will transport a given message stream
over exactly one byte stream.
Datagrams; MEMUX provides message stream connections.
Control channel vs. data channel separation; that distinction is to be
made at a higher layer, which will use MEMUX's service for whichever channel(s)
Goals and Milestones
1999/03 - WG chartered.
1999/06 - MEMUX goals submitted to IESG for publication as Informational
1999/10 - MEMUX specification submitted to IESG for publication as Proposed
Interest in a multiplexing protocol appeared at IETF-43 in the HTTPNG,
RUTS, SIGTRAN, MEGACO, and AAA meetings. The HTTP-NG
proponents submitted a draft multiplexing protocol (draft-gettys-webmux-00.txt)
on 1 August 1998 as part of the HTTP-NG suite.