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 barnes@xylogics.com Julian Bates bates@xylogics.com David Borman dab@cray.com Peter Cameron cameron@xylint.co.uk Les Clyne l.clyne@jnt.ac.uk David Crocker dcrocker@mordor.stanford.edu Sun-Kwan Kimn sunkimn@hp.com Andrew Knutsen andrewk@sco.com John Krawczyk jkrawczy@wellfleet.com Kent Malave kent@bach.austin.ibm.com Gary Malkin gmalkin@xylogics.com Allison Mankin mankin@cmf.nrl.navy.mil Marjo Mercado marjo@cup.hp.com Greg Minshall minshall@wc.novell.com Douglas Williams dougw@ralvmg.vnet.ibm.com Gordon Young young@xylogics.com