CURRENT_MEETING_REPORT_
Reported by Jim Barnes/Xylogics
Minutes of the TCP Multiplexing BOF (TMUX)
Agenda
o Introduction
o CMP Presentation
o Discussion
o Alternative proposals
o Where do we go from here
Discussion
The TMUX BOF began with Peter Cameron's presentation on the Connection
Multiplexing Protocol (CMP). The CMP protocol is defined in the
Internet-Draft: draft-cameron-cmp-01.txt.
A couple of changes have been made since the last version was published.
One change was the removal of the close reply message type. This
message type is replaced by just sending the close message in response
to a received close, just as TCP sends a FIN in response to a received
FIN.
During the following discussion, a number of issues were raised:
o How would the implementation of CMP on top of TCP affect the TCP
window dynamics?
o CMP may be fine for multiplexing a large number of small packets
but if FTP connections are multiplexed, the FTP subconnections will
fight each other for available window space.
o The idea of falling back to a normal TCP connection if a request to
open a CMP connection fails was well received.
o There will necessarily be bandwidth reduction due to the multiplex
protocol headers.
o A misbehaving CMP client may exceed the allowed credit and force
the receiver to control the flood with the TCP window mechanism.
o Performance versus complexity of implementation was mentioned as a
possible issue.
Kent Malave briefly described his experiences when multiplexing SPX
packets. The reasons for doing the multiplexing, and the experiences in
implementing the protocol, were similar to those behind CMP.
Dave Crocker gave a brief presentation of an alternate proposal. TMux
is a multiplexing protocol between the IP and TCP layers (in contrast to
CMP which is a layer on top of TCP). The apparent advantages of TMux
over CMP were largely due to the simplicity of the design. Someone
noted that there were no delay timers in the protocol.
When discussing the advantages of one proposal over another, it was
noted that:
o Data loss in CMP will cause delays in all other TCP data over that
connection until the lost packet was retransmitted.
o TMux will require that the multiplexed packets are padded so that
each multiplexed packet starts on a word boundary.
o A single bit error in a CMP packet requires that the entire packet
be retransmitted. A single bit error in a TMux packet will require
only the erroneous packet to be retransmitted, but the other
multiplexed packets in the IP packet can be delivered to the
application.
Allison Mankin discussed the concern that the IESG has with changing the
architecture. When describing what would be significant issues in the
IESG approval process, steady-state performance was deemed to not be a
deciding factor. The main issues would be the required architectural
changes to the protocol stack, the ease of implementation of any
solution, and the behavior of the protocol under aberrant conditions.
When the chair requested a consensus on what to do next, the following
suggestions were made:
o A test implementation of TMux should be done and compared with CMP
keeping the above decision criteria in mind.
o The TMux proposal should be published as an Internet-Draft.
o Greg Minshall will investigate the availability of documentation
describing the NPI protocol between the IP and TCP layers in System
V.4.
Attendees
Jim Barnes
[email protected]
Julian Bates
[email protected]
David Borman
[email protected]
Peter Cameron
[email protected]
Les Clyne
[email protected]
David Crocker
[email protected]
Sun-Kwan Kimn
[email protected]
Andrew Knutsen
[email protected]
John Krawczyk
[email protected]
Kent Malave
[email protected]
Gary Malkin
[email protected]
Allison Mankin
[email protected]
Marjo Mercado
[email protected]
Greg Minshall
[email protected]
Douglas Williams
[email protected]
Gordon Young
[email protected]
