Re: draft-cameron-tmux-01.txt

[Pete Cameron <[e-mail]>]

Donald,

On Nov 2,  2:54am, "Beast (Donald E. Eastlake 3rd)" wrote:
> Subject: Re: draft-cameron-tmux-01.txt
> ...
> 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.

I have been rethinking this.  We did look at using the TOS
field as you suggested in 2B, but rejected it because  no
one used it. However you are right, we should not totally
ignore it.

There is an easy solution to this problem. I think we need
to add a paragraph into the document (somewhere) that says
something like:

        On reception of a TMux packet, a new datagram is
        reconstructed from that given in the TMux message,
        with an IP header duplicated from the IP header
        given to the TMux packet, with the 'protocol' and
        'length' fields filled in from the TMux mini header.

This is exactly whet we do in both of our test
implementations, and it works well.  What this would then
do, is ensure that all reconstructed datagrams have the same
TOS field.  We would then have to mandate that we use the
TOS field as a selector to which (if any) TMux packet each
source datagram is inserted into.

We then have two ways of dealing with the TOS field, both
of which are equally valid:

1)      Only TMux datagrams with a TOS value of zero (ie.
        almost the current way of doing things).

2)      Have separate TMux packets under construction for
        those TOS valuse that we think we should multiplex.
        Those that require fast delivery would not be
        multiplexed.

In fact 1 is a degenerate case of 2, which is (I think) your
original suggestion.

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

This was a suggested technique, but I don't like it. It does
not scale to a large network like the Internet. There is
nothing in the ID that stops you using a prior arrangement
scheme, only a suggested alternative.

> ...
> I just wanted to point out there are other reasonable implementation
> strategies.

I agree. I have tried to put together one scheme that I
think works, and that has the correct dynamics for a large
network or a small network. This is not our first scheme,
and I am sure other schems work well, but this is the one I
like. If there is a good reason for another, I am quite
willing to change (it would not be the first time in this
process, see the original CMP ID, that's very different!).

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

If you are interested, maybe we could meet outside the BOF
for a chat over a coffe or beer some time?

Pete


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