Reducing the UMTP 16 bytes overhead

[Doron Rajwan <Doron@bandwiz.com>]

Ross,

I suggest to use UMTP-lite protocol, that will work only with SSM sessions.
The overhead of this protocol can be reduced to 0 bytes!

The current 16 UMTP bytes overhead contains:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 (IPv4) source address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         source cookie         |       destination cookie      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 (IPv4) multicast address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              port             |      TTL      |S|vers.|command|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


My suggestion is to use a directional tunnel, from the slave to the master,
per (S,G), for SSM sessions. If you want to tunnel more than one group --
create more than one tunnel (you need the state anyway). In this case, you
can remove the source address (S) and the multicast address (G). Also, I
think that the cookies are redundant because there is no need to give
greater protection than SSM; we can relay on the RPF checks.

This leaves us with 4 bytes overhead. In order to remove those too, the port
number should be fixed. It means, that if a multicast application sends data
to the same (S,G), but to a different port, this data cannot be tunneled.
The TTL field is set to zero, i.e., only the tunnel master computer. The S
is always 1, The version is always 0, and the command is always DATA. The
tunnel creation / destruction commands will be set to a well-known port on
the slave.

The benefit: 
1. Simple protocol.
2. No IP fragmentation needed!

Doron.




-----Original Message-----
From: Ross Finlayson [mailto:finlayson@live.com]
Sent: Sunday, February 25, 2001 1:00 AM
To: Doron Rajwan
Cc: dino@procket.com; Radia Perlman (E-mail)
Subject: RE: FW: New Internet Draft on automatic (end-user) tunneling
for SSM


At 11:37 AM 2/24/01, Doron Rajwan wrote:
>Still, I think that you can discard the original IP / UDP headers: The
>source IP (S) and the destination IP (G) are known to the receiver, because
>they were given on the tunnel creation.

But remember it's possible for *more than one multicast session* to be 
tunneled at the same time.  I.e., the end node may have joined several 
different multicast groups, with several different SSM sources, and with 
different destination UDP ports (e.g. RTP,RTCP).  When multicast data comes 
over the tunnel, the tunnel master (i.e., running on the end node) needs to 
know this information (which came from the original UDP/IP header) so that 
it can know which multicast session it belongs to.  That's what the UMTP 
trailer is for.

Now, one could argue for a simplification of UMTP in which the UMTP trailer 
- for "DATA" packets - doesn't need to carry all of this information in 
detail.  Instead, the DATA packet could just carry some sort of 'token' 
that indicates which multicast session the data is for.  This 'token' could 
be some random number that's chosen randomly by the tunnel master and 
included in the "JOIN_GROUP" message along with the (S,G,P) 
information.  If this is done, then the full (S,G,P) information would be 
present only in the periodic JOIN_GROUP messages that are sent by the 
master, *not* in the (possibly far more frequent) DATA messages that come 
back from the slave.

I think that this would be a useful change to make, and something to 
consider for 'UMTP-light'.  (The reason why the current UMTP doesn't do 
this is that it allows for the possibility of DATA packets being sent 
across the tunnel for multicast sessions that were *not* explicitly 
requested by an earlier JOIN_GROUP.  But for our purposes, that's not
needed.)

However, note that other, 'router type' people on the MBONED and SSM 
mailing lists are currently arguing in the opposite direction: They're 
arguing that - to simplify implementation in the router (the tunnel slave) 
- the DATA packets should contain the *whole* original UDP/IP header (a 
28-byte overhead), rather than any simplified representation of this.  I'm 
not sure how much I believe their arguments, but in order for this 
tunneling mechansm to get used, we need to get buy-in from router 
people.  If that means putting up with some wasted overhead, then I can 
live with that...

>The application will not put any de-multiplexing information in the port
>numbers.

No, there should be no need to impose *any* restriction on applications 
(other than that they use UDP).

         Ross.