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 firstname.lastname@example.org 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 multiplexing protocol to
provide a certain set of services, articulated below. MEMUX is not
an attempt to solve all of the world's problem, nor even all the ones articulated
at the RUTS BOF at IETF-43 (http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html).
The MEMUX protocol is to deliver multiplexed bidirectional reliable ordered
message streams over a bidirectional reliable ordered byte stream protocol
(such as TCP). Message streams may be initiated by either side, once
the underlying byte stream connection is established. 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 for there to be multiple message chunks in 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
Due consideration will be given to the concerns of the IPv4->v6 transition
and the use of NATs.
Some details of requirements remain to be worked out, depending on the
interests of, and needs represented by, the participants. One such
issue is the desired kind(s) and degree(s) of insluation, or even control
of interaction, between message streams multiplexed over the same byte
stream. Another is the desired kind(s) of endpoint identifiers.
Another is whether MEMUX, perhaps with a slight adaptation layer, is to
be usable by MEMUX-unaware applications through an interface designed to
present TCP's service (e.g., sockets); this in turn raises a question (in
some people's minds) of whether both peers in such a scenario should be
required to have MEMUX in their stacks.
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; that protocol could serve
as MEMUX, depending on how the open requirements questions are settled.
An Informational RFC on the goals of the MEMUX protocol.
Standards-track specification of the MEMUX protocol.
Out of Scope
Inventing new byte stream protocols; MEMUX is to use existing (e.g., TCP)
or new ones.
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