Re: draft-cameron-tmux-01.tx

["Beast (Donald E. Eastlake 3rd)" <[e-mail]>]

Somehow the last letter got dropped from the list email address below...

------- Forwarded Message

Message-Id: <[e-mail]>
To: [e-mail] (Pete Cameron)
Cc: "Beast (Donald E. Eastlake 3rd)" <[e-mail]>, [e-mail].u
Subject: Re: draft-cameron-tmux-01.txt 
In-Reply-To: Your message of "Mon, 01 Nov 1993 21:49:56 GMT."
             <[e-mail]> 
Date: Tue, 02 Nov 1993 02:54:01 -0500
From: "Beast (Donald E. Eastlake 3rd)" <[e-mail]>


Pete,

From:  [e-mail] (Pete Cameron)
In-Reply-To:  "Beast (Donald E. Eastlake 3rd)" <[e-mail]>
	            "draft-cameron-tmux-01.txt" (Nov  1,  3:08am)
To:  "Beast (Donald E. Eastlake 3rd)" <[e-mail]>,
            [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.

I have three answers to your first answer:

(1A) In an environment where TOS is not used, it will always be zero
so the datagrams *will* always have the same TOS and can be combined
and the resulting Tmux datagram will also have zero TOS.

(1B) In an environmnet where IP TOS is used, you *must* check that it
is the same when combining datagrams so they get the correct handling
/ routing by making the Tmux packet have the same TOS as its enclosed
datagrams.

(1C) <flame on> Look, TOS is part of the mandatory IP with full
protocol status.  The Tmux document does not seem to be the right
place to change that.  I suggest firing datgrams with random TOS
values in them at routers and hosts this will crash until their brain
damaged software is fixed. Interoperability is encouraged by
implementing the mandatory parts of the protocol standards, not by
breaking when they are invoked. <flame off>

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

I have two answers to your second answer:

(2A) Of the 16 TOS values, 6 of which have defined meanings, only one
requests the fastest available service.  You can still Tmux the others
which are: default, maximum bandwidth, maximum reliability, minimum
cost, and maximum physical link security.  In fact, the maximum
bandwidth and to some extent the minimum cost TOS's seem like
excellent candidates to Tmux with nice long delays (although they also
seem like cases where the packets might be too long to Tmux together).

(2B) You are still locked into much too specific an implementation
point of view here.  In a dinner discussion earlier this evening, I
was discussing Tmux and someone pointed out that it would probably
provide a good portion of the benefit if all you did was the
following: when adding a packet to your output queue, if it is small,
see if the last queued packet is for the same host and TOS and is
either (a) small, in which case you make it a Tmux and insert what you
were going to queue, or (b) already a Tmux with enough space to add
thix next packet, in which case you insert it.  With this strategy,
you mostly Tmux when the net is getting a bit congested and don't add
any significant delay.

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

I remain convinced that ignoring TOS is fundamentally wrong.

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

Well, I suppose you should simply point out that it may be difficult
to use this technique for broadcast packets because of the requirement
that they all be able to receive Tmux.  So in this case it might be
better to use/not-use Tmus by prior arrangement rather than Tmux-ENQ.

}> 	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 just wanted to point out there are other reasonable implementation
strategies.

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

Sounds goods...

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

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

Unfortunately, it looks like I won't be able to make the Tmux BOF as it
is opposite an IPSEC meeting.

Good Luck.

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


------- End of Forwarded Message