Re: New Internet Draft on automatic (end-user) tunneling for SSM

[Ross Finlayson <finlayson@live.com>]

At 07:26 AM 2/24/01, Tom Pusateri wrote:
>But tunneling can be done in many ways including encapsulation,
>rewriting headers, adding source route options, etc.
>
>So when talking about overhead, please be more clear about exactly
>type of tunneling is going on.

OK, fair enough.  To recap: The 'tunneling' that we are talking about here 
is UDP multicast tunneled over UDP unicast - i.e., using a UDP unicast 
packet A to (somehow) carry the semantics of a UDP multicast packet B, so 
that the node that receives packet A can reconstruct (as appropriate) the 
semantics of B (for delivery to the end application).  Once again, it's 
important to stress how important it is that the 'outer' packet be ordinary 
UDP (unicast) - because this allows every computer in the world to receive 
(a large class of) IP multicast sessions, without requiring that their 
users install a new networking stack, or worse, a new OS.

If you have both a "router developer's hat" and an "application developer's 
hat", then you should wear the latter hat when thinking about UMTP, because 
it is simply a protocol originally designed for tunneling between agents 
that are capable of running as ordinary applications.

A UMTP "DATA" packet is simply a UDP unicast packet, whose UDP payload 
contains two things:
         - the payload from the original UDP multicast packet, and
         - a 16-byte trailer that describes the semantics of the multicast 
packet,
           in particular: its destination group address, its SSM source 
address,
             and its intended destination UDP port.
So, the overhead of UMTP - when tunneling a SSM packet - is exactly 16 
bytes.  (If desired, this could probably be reduced some more with a 
'UMTP-light' that omits things (like the ttl field) that aren't necessary 
for the special case of router<->end-node tunneling.)

>If UMTP rewrites the original header plus adds the trailer,
>it adds just the trailer which is 12 or 16 bytes.

That's correct (although - wearing an "application developer's hat" - I 
prefer not to think of it as 'rewriting the original header').  It's just 
taking the payload from the original UDP multicast packet, adding a (12 or 
16-byte) trailer, then resending it in a new UDP unicast packet.  People 
who wear "router developer's hats" are welcome to think of this another way 
if they prefer :-)

>I would request that Ross clarify draft-finlayson-umtp-05.txt
>about the use of encapsulation and header rewriting.

Will do.  It's clear that I've confused people by my (apparently incorrect) 
use of the term "encapsulation".  My apologies; I'll fix this in future 
versions.


>GRE adds: 24 bytes (20 byte IP + 4 byte GRE header)

Except remember that our goal here is UDP(multicast)-over-UDP(unicast) 
tunneling.  If you were to use GRE to encapsulate (using the term correctly 
this time :-) a UDP multicast packet within a UDP unicast packet, then this 
would add 32 bytes (20 byte IP + 8 byte UDP + 4 byte GRE header).

>IPIP adds: 20 bytes (20 byte IP)

I don't think IPIP is an option here, because the 'outer' packet needs to 
be UDP.

>A clarification on this would be great.

I hope this helps!  (I'll also be giving a spiel on UMTP as part of the 
automatic tunneling presentation during MBONED in Minneapolis.)


>Of all of these options, GRE or IPIP are simplest to implement in hardware
>which will give you the performance and scaling needed for large rollouts.

Right, although we also need to think about ease of deployment for end 
users, which seems to dictate the use of a UDP-based tunneling protocol, 
which would rule out IPIP.

As for GRE (within UDP unicast): If routers can, indeed, implement this 
significantly more efficiently than UMTP "DATA" packets, and we don't mind 
the extra overhead (32 bytes for GRE versus 16 bytes for UMTP (or less for 
'UMTP-light')), then I agree that we seriously consider using GRE 
instead.  (Note, though, that UMTP 'control' packets - or something like 
them - would still be needed in the reverse direction - to signal 'joins' 
(plus periodic keep-alives) and 'leaves'.)

I'm looking forward to getting more feedback from router folks about all 
this...

         Ross.