draft-cameron-tmux-02.txt

["David A. Borman" <[e-mail]>]

I've just finished reading over the lastest TMux draft.  It
looks pretty good to me, but I do have 4 items.

First, on page 8, in the Protocol Example, the packet layout
shows the third TMux segment, a UDP packet, as having a UDP
header but with TCP data...

Second, in section 2.3, page 5, it describes an ENQ message
as an empty TMux message, i.e., an IP datagram with a protocol
field of 18, and the IP data length set to zero.  This is
wrong, an IP datagram with no data will have the IP data
length set to 20, not zero, since the IP data length includes
the IP header.

Third, I've brought this up before at the IETF meetings, and
it still bothers me that there is only an ENQ message, and no
explicit response message.  Section 2.3 says that if an ENQ
message is received, but the receiver does not intend to send
any TMux packets, that it can respond with another ENQ message.
Then in the implementation notes in section 6 it talks about
sending an ENQ in response to an ENQ as being problematical in
that loops of ENQ messages might be generated, so logic must
be included to prevent these loops.

Wouldn't it be a lot easier to just define an RSP (response)
message, that is never responded to?  Then if you get an ENQ,
you can either start sending TMux packets, or send an RSP so
that the other side can start sending TMux packets.  It will
never respond to the RSP, so there is no potential for loops,
and you disallow sending an ENQ in response to an ENQ.  Seems
a lot simpler to me.

I really don't care about what an RSP packet looks like, just
so that there is one distinct from an ENQ packet so that the
whole looping ENQ messages issue can avoided.

How about:
	ENQ: IP length = 20, Proto = TMux
	RSP: IP length = 21, Proto = TMux
		one byte of data, set to 0 on output,
		and ignored on input.

The TMux input logic has to check for a data length of zero
(after stripping the IP header) to identify an ENQ message,
and it also has to check for a data length less than 4 (the
minimum size of a TMux packet, since the TMux header is 4
bytes long).  These can be combined, along with checking for
an RSP message in one check for a data length less than 4,
and then checking again to see exactly what the data length
is.  Thus the input processing for a regular TMux packet is
not affected by adding an RSP message.

	/*
	 * We got a TMux message.  Mark the remote host
	 * as TMux capable, and reset its TTL timeout.
	 */
	...

	/*
	 * Check for short TMux messages
	 */
	if (datalen < 4) {
		if (datalen == 0) {
			/*
			 * An ENQ message.
			 * Send a RSP message if we don't intend
			 * to send any TMux messages in the near
			 * future.
			 */
			...
		} else if (datalen == 1) {
			/*
			 * An RSP message.
			 * Don't do anything, we've already marked
			 * this host as TMux capable.
			 */
			...
		} else {
			/*
			 * Shouldn't happen.  Ignore the message.
			 */
		}
		/* Free the message, and */
		...
		return;
	}
	/* process the TMux packet ... */

To be quite honest, if there is not an RSP message defined, as an
implementor I'd be real inclined to define one anyway just to avoid
the whole ENQ looping issue.  All I'd need is some type of TMux
message that would cause the other side to decide that I can receive
TMux messages.  I'd probably define an RSP message something like:

	IP length = 24, Proto = TMux, TMux.length = 4, TMux.proto = UDP

and hope that it causes the right thing to happen, but I'd much rather
have an official RSP message.

Fourth, I'm not quite clear on the TTL discussion in the second half
of section 2.3.  It states that every time a TMux packet is received,
the TTL for that host is reset.  If I am sending a packet that can
be TMuxed and the TTL has expired, then I send it as a TMux packet
anyway, and if the remote host no longer supports TMux, the transport
layer will cause a retransmission of a non-TMux packet.

Does this mean that if the TTL has expired, I create a TMux packet
and send it immediatly, or do I defer it as I normally would, waiting
for more packets to multiplex with it?  And once I decide send it, do
I then delete this host from my list of TMux capable hosts, so that the
next send will send a normal IP packet, along with an ENQ message
(in case that what happened was the first TMux packet got lost, not
that I didn't get a response)?

What if the other side isn't going to be generating any TMux
traffic back in the near future (just like when an ENQ message is
sent)?  I need to get some type of TMux packet to cause the TTL to
be reset and mark the remote host as TMux capable again.  Should the
remote side be using its TTL list to know when an incoming TMux packet
is one that *has* to be responded to, so that the other side can keep
sending TMux packet?  (An RSP message would be ideal in this case
if the remote host knows that it won't be generating any TMux
traffic in the near future...)

And what if the traffic is UDP, which doesn't have any retransmission
at the transport layer?  Instead of sending it as a TMux message,
should it be sent as a regular UDP datagram, and also send an ENQ
message to see if the TMux is still supported?  Or should we just
not worry about the rare occurance when the TMuxed UDP packet gets
dropped because the other side no longer supports TMux, since TMux
is mainly intended for telnet/rlogin traffic, both of which are TCP?

			-David Borman, [e-mail]