Re: draft-cameron-tmux-01.txt

[Pete Cameron <[e-mail]>]

Donald,

Thanks very much for your interest.

On Nov 1,  3:08am, "Beast (Donald E. Eastlake 3rd)" wrote:
> Subject: draft-cameron-tmux-01.txt
> 
> First of all, I think this is a great idea.
> 
> My comments:
> 	This draft is much too terminal server exclusive.  That may be
> the most important initial use of Tmux but it seems to me that there
> are lots of cases of frequent traffic between hosts that could be
> accumulated.  For example, messages between IRC servers.

I started off with something that was rather based on the
requirements of terminal servers, and have been trying to
tone that down, I thought I had done that by restricting
these comments to the introduction, I need to re-read things
again!

I fully agree that it is applicable to other uses, and other
uses are appearing - a sign of an idea who's time has come?

> 	The protocol is only applicable if the datagrams to be grouped
> have the same TOS (Type of Service) and the combined Tmux packet must
> have the TOS of the combined datagrams.

I have two answers to this:
1)      TOS is never used(?) and indead, some IP
        implementations break if you use TOS causing
        interoperability problems.

2)      TMux should only multiplex packets that do not
        require fast delivery, as the timers do slow things
        down.

For thes two reasons, we chose to ignore the TOS field.

> 	The document should point out that this technique is
> applicable to broadcast packets as well.  It just matters that the
> destination addresses and TOS be the same and the combined packets fit
> into the MTU.

Yes, you could multiplex broadcast messages in theory.
However, you then have to decide which of the hosts in the
broadcast domain support TMux and which don't, which you are
building packets for etc... It becomes a mess. Far better to
just let them through as is.

> 	I was happy to see the change from 00.txt to allow longer Tmux
> packets.
> 	A lot of other things in the draft just seem too specific.
> For example, a host might just want to sent a Tmux ENQ back right away
> when it received one to avoid any question of whether it happened to
> have any Tmux'able traffic sitting around if it wanted to Tmux.

The basic protocol does not require the way TMux ENQ packets
are handled, it just gives suggestions. However, I think
this scenario could be a common one, so I think I will add
it as an option.

> 	The references to "the" Multiplexed Message under contruction"
> seem odd.  There could be many (e.g., an IRC server that talked to two
> or three other IRC servers might have enough traffice for each of them
> to justify Tmux'ing. 

This was my attempt to simplify things. There could (in
general will) be many packets under construction, one for
each host that supports TMux and for which we have tried to
send packets.

> Conceivably on some systems, you could patch
> together packets sitting in your Ethernet or whatever output queue on
> the fly and Tmux more as things get more backed up (probably not a
> good idea in general but another conceivable strategy). 

One of the principles behind TMux, is that for it to work,
it must be quick to execute, hence simple. I think that this
idea is pushing this just too far. However, if people want
to do this...

> I also don't
> see where this "30 octet" suggested limit comes from.  Even with an
> MTU of 500 octets, it might make sense to Tmux things up to 100 octets
> and even more for a larger MTU.

Yep, you are right. In our latest development code we use a
max size of about 100 bytes, works just great. We have also
run sizes of 1500 octets, in the right situation, this is
also good. What it allows, is window update packets to be
piggybacked onto large data packets, a nice saving.

> 	Under Security Considerations, Tmux isn't a TCP port number,
> its an IP protocol.  I think the paragraph should be re-written to
> spell out the results of the three primary choices (let Tmux through:
> no security for small datagrams that are Tmux'ed; block Tmux: hosts
> will think it not implemented and not use it; understand Tmux:
> efficiency of traffic with security).

Well spotted. I wrote this paragraph in haste, so I will
regret at leisure! It needs a total rewrite, the way you
suggest seems good.

> 
> Donald
> 
> *+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-
>  Donald E. Eastlake, III     1-508-486-6577(w)     [e-mail]
>  PO Box N, MIT Branch PO                           [e-mail]
>  Cambridge, MA 02139 USA     1-508-287-4877(h)


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