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

From: Ross Finlayson <[email-masked]>
Date: Fri, 23 Feb 2001 23:35:15 -0800

>    o Also, justify why you're not using GRE.

Dino (et al),

Let me apologize for my somewhat flippant response to your earlier question 
about not using GRE (especially since at the time I had forgotten that you 
were one of GRE's authors :-) :-)

I do remember considering GRE when I first designed UMTP (back in 1997).  I 
took another look at the GRE spec just now, and I can now recall why I 
chose not to use GRE - the space overhead would have been too great.

 From my understanding of GRE (please correct me if I'm wrong), the 
overhead to tunnel an arbitrary UDP multicast packet using GRE would be 32 
bytes: 4 bytes (for the GRE header), plus 28 bytes (for the UDP/IP headers 
of the encapsulated packet).

In contrast, UMTP adds an overhead of just 16 bytes (when carrying a SSM 
packet - it'd be 12 bytes for ISM).  Furthermore, by making this a trailer, 
rather than a header, RTP/UDP/IP header compression - if applied - will 
continue to work on the entire packet.  (The space savings could be 
significant if the UMTP packets traverses a low-bandwidth link...)

(Also, the same 16-byte trailer turns out to be useful for sending control 
packets (in the reverse direction from data) - e.g., JOIN_GROUP (including 
periodic 'keep alive's) and LEAVE_GROUP messages.)

         Ross.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 24 Feb 2001 02:07:19 -0800

>> of the encapsulated packet).

    The overhead is an additional 24 bytes (20-byte fixed IP header and 4-byte
    GRE header).

Dino

---

From: Ross Finlayson <[email-masked]>
Date: Sat, 24 Feb 2001 02:37:20 -0800

>     The overhead is an additional 24 bytes (20-byte fixed IP header and 

But what about the UDP header of the packet that's being tunneled (i.e., 
the inner packet)?  That's another 8 bytes.  Wouldn't that go in the GRE 
packet as well?

         Ross.

---

From: [email-masked] (Jeremy Hall)
Date: Sat, 24 Feb 2001 09:07:42 -0500 (EST)

Maybe I'm missin somethin obvious, but why encapsulate the original packet
inside a UDP packet and THEN inside a GRE packet? Wouldn't it make more
sense to just encapsulate the original thing in a GRE packet?

_J

---

From: Randy Bush <[email-masked]>
Date: Sat, 24 Feb 2001 06:15:42 -0800

premature optimization is the root of all evil
  -- tony hoare

---

From: Randy Bush <[email-masked]>
Date: Sat, 24 Feb 2001 06:25:15 -0800

> premature optimization is the root of all evil

whoops!  that may have been don knuth.

randy

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 24 Feb 2001 07:26:33 -0800

>the inner packet)?  That's another 8 bytes.  Wouldn't that go in the GRE 

I'm confused and possibly others are as well. The word encapsulate
has a very specific meaning while the word tunnel does not.

Encapuslate means "to enclose" which, when dicussing packets, should
be interpreted to mean to add octets in front of, or add
octets at the end, or both.

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.

Ross suggested that UMTP's trailer is to allow normal RTP header
compression. Looking at the UMTP spec, it is difficult to determine
if the original IP headers are rewritten or not. I assume so
since it looks like the old IP header info is stored in the trailer.
This should not be called encapsulation if the headers are
modified before the trailer is added, or at least the
word rewrite should be used in conjunction with the word
encapsulate. This is tunneling though.

Dino's GRE mechanism is simply adding a new IP header and GRE
header in front of the original IP header without modifying the
original IP datagram. This is a true encapsulation. This is also
a form of tunneling.

A major advantage to encapsulation over option insertion or IP
header rewriting is that routers already do this in existing
hardware. Other tunneling mechanisms that use header rewriting or
option insertion are more difficult or impossible to do in hardware
causing them to be shifted to valuable general purpose CPUs. Some
routing vendors will refuse to implement these schemes.

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

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

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

If UMTP encapsulates the original packet with IP and UDP and adds the trailer,
it adds: 48 (20 byte IP + 8 byte UDP + 16 byte trailer)

If UMTP strips the IP header, adds a new UDP header and a trailer, its adds
24 (8 + 16 byte trailer).

A clarification on this would be great.

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.

Thanks,
Tom

---

From: Ross Finlayson <[email-masked]>
Date: Sat, 24 Feb 2001 11:13:09 -0800

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

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

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

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

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 24 Feb 2001 11:33:01 -0800

>who wear "router developer's hats" are welcome to think of this another way 

Got it. I guess I think of rewrite because a router won't forward these
at the socket level but at the IP level.

>would add 32 bytes (20 byte IP + 8 byte UDP + 4 byte GRE header).

I think this is where things were confusing. There is no UDP associated
with GRE. Its pure IP just like IPIP.

>(plus periodic keep-alives) and 'leaves'.)

There is no point using GRE with UDP.

I forgot to include another posbbile encapsulation option which is
IP/UDP. This adds 28 bytes (20 bytes IP + 8 bytes UDP) to the front of
the packet and doesn't change the original IP datagram (header included).

This would be my preference if UDP unicast is required.

Thanks,
Tom