Re: draft-cameron-tmux-02.txt

[Pete Cameron <[e-mail]>]

---------  Received message begins Here  ---------

> From [e-mail] Wed Feb  2 19:02:09 1994

Dave,

Thanks for the comments. Sorry I took so long to reply, I
was over in our US office for a few days and wanted to talk
to one of my colegues about this first. Anyway, here are my
replies.

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

Thanks for that.

> 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...

Well spotted.

> 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.

Well spotted again.

> 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.
> (text deleted)

I agree with Dave Crocker's point here.  We tried to make
this as simple as possible, and for that reason we had the
simple ENQ system.  We have tried this out, and it works
particularly well for TCP trafic.

I have been thinking for a while that we should remove the
more general use of TMux that allows it to work with other
protocols such as UDP as this leaves a few inconsistancies.
In particular, we state in section 5.2 that only Telnet and
Rlogin traffic should be multiplexed.  This implies that UDP
can not be multiplexed.  I also note that explicitly
restricting things to TCP would help to clear up some of
your comments below.  Any comment on this from anyone on the
mailing list?

> 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)?

Your long explanation is correct. I will look at the text to
see if I can make it clearer.

> 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...)

The TCP ACK will act as the RSP message in this situation.

> 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?

See my comment above on UDP.

There is another way of looking at this. It is a situation
that almost never occours (a system thst did support TMux
no longer supporting it), so the occasional loss of a packet
is not something to get excited about. In particular, we
appear to UDP to be IP, so UDP expects that packets may get
lost, so no great problem.

I hope this clears things up a little.

Pete Cameron                                            tel: [phone]
Consulting Engineer                                     fax: [phone]
Xylogics International Limited                  email: [e-mail]
Featherstone Rd, Wolverton Mill, MK12 5RD, UK.         [e-mail]