Message Multiplexing (memux) Charter

Name | Area | Chairs | Directors | Mailing List | Description | Goals & Milestones | Background

Working Group Name

Message Multiplexing (memux)


Transport Area


Transport Area Directors

Responsible Area Director

Vern Paxson

Mailing List

The <> mailing list and archives 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 for details.

Description of Working Group

The goal of this working group is to standardize 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 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, and multiplex many message streams over a single byte stream connection.  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.

Goals and Milestones

Background Information

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.