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

[Ross Finlayson <finlayson@live.com>]

At 01:17 PM 2/28/01, Hugh LaMaster wrote:
>The end-user still has to have a UMTP-enabled app, though, right?

One possible approach is for each multicast application to support UMTP (or 
whatever UDP-based tunneling protocol ends up being defined for automatic 
tunneling).  Another possible approach is for the helper app, shell or 
plugin that *launches* the application to support this tunneling 
protocol.  For example, if you launch your application from a SDP session 
browser, then this browser can perform the tunneling itself.  The browser 
receives incoming tunneled traffic, and re-multicasts it locally (i.e., 
with TTL 0) where it can be received by existing multicast applications 
(without modifying them).

For example, the "multikit" multicast session browser (available for free 
from <http://www.live.com/multikit/>) already has a tunneling option, and 
several people have used this to tunnel multicast sessions over 
non-multicast-capable routers. (In this case, the tunneling isn't 
automatic; instead, the user has to explicitly specify a UMTP 'slave' 
(e.g., a liveGate server) that's located on a separate, multicast-enabled 
network.)

>Do UMTP-enabled versions of, say, vic and vat exist today?

No, although - as noted above - they can (& do) work without change by 
having the launcher tool do the tunneling.

>Do existing apps offer automatic switchover (start
>with multicast, switch to UMTP if nothing happens?)

No, although "multikit" sort of does the reverse: It lets the user start up 
a (non-automatic) tunnel explicitly, but turns it off if it detects that 
it's not necessary.

In practice, I don't think that deploying application support for multicast 
tunneling is going to be a significant hurdle.  The most widely deployed 
media players (e.g., RealPlayer and Windows Media Player) already have 
mechanisms for automatically downloading new plugins on demand.  (Ditto for 
web browser plugins.)  Just as long as we don't require *OS* 
upgrades...  In contrast, the biggest hurdle is going to be to persuade the 
router vendors to bundle tunneling slave support with their PIM-SSM 
implementations.

>So, it is a big deal to ask the router
>operating system to catch all the packets of a certain type and
>process them in software, and it opens up the possibility of DoS,
>on-purpose, or perhaps accidentally.  If the core router could
>dumbly forward all request packets to a nearby helper, I would
>think that would help a lot.

Agreed.  Router vendor buy-in is (obviously) essential here, and the 
tunneling protocol should be designed with ease of router support in 
mind.  (For example, we've already heard some feedback that it's easier for 
routers to send tunneled multicast packets to the end nodes using 
encapsulation (IP/UDP) rather than header rewriting+adding a trailer (which 
is what UMTP's "DATA" command does now).

One possibly useful way to proceed now would be to break the problem up 
into three parts:
1/ The UDP-based *signalling* protocol that end nodes (tunnel 'masters') 
would use to join (with periodic keep-alives) and leave multicast 
groups.  This could be something similar to UMTP's "JOIN_GROUP" and 
"LEAVE_GROUP" commands.
2/ The UDP-based *data delivery* protocol that tunnel 'slaves' (ideally, 
compliant routers) would use to deliver multicast data to the end 
nodes.  (This might just be a simple encapsulation protocol.)
3/ One or more possible 'router behaviors' that would implement automatic 
tunneling.  The current draft talks about one such 'behavior': "Upstream 
router interception".  This seems like the simplest behavior to support, 
but one could imagine extending it to support things like more complicated 
hand-off, etc...

The key point here is that we can define the end-user signalling and 
delivery protocols (1/ and 2/) for automatic tunneling, while leaving room 
for some flexibility as to how routers actually implement this (i.e., 3/).


>UMTP seems like a lot of work to develop/debug/deploy.  I think
>the same level of effort applied to deploying native multicast
>might bring more multicast users online.

Perhaps, but its effort that would be applied in different places.  There's 
nothing to prevent us from attacking both fronts; in fact, there are good 
reasons why we should do this.  There are lots and lots of legacy first-hop 
routers out in the Internet that don't support native multicast.  They are 
never going to get upgraded to support multicast unless we provide some 
incentive.  The availability of UDP-tunneled multicast (which allows all of 
these users to experience multicast sessions ASAP) can provide such an 
incentive, by creating demand for the deployment of native support (to 
improve performance).  "Build it, and they will come" :-)

         Ross.