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

[Hugh LaMaster <lamaster@nren.nasa.gov>]

On Mon, 26 Feb 2001, Jon Crowcroft wrote:

> so a non multicast receiver can find _A_ unicast (or if anycast RPs
> are used, even maybe an anycast, though i guess someone on anISP that
> doesnt allow end users multicast probably doesnt let them use other
> useful things too - hey, they probably are behind a nat too:-)

And, once they discover all this tunnel traffic, they'll probably
start filtering it.  I'm guessing that the success of UMTP depends 
on "anISP" being slow on the uptake  ;-)
 
> anyhow, so rathwerthan something complex for the end user, lets
> propose this

The end-user still has to have a UMTP-enabled app, though, right?
I think that will add complexity for the end user, not to mention
the app developers.  Do UMTP-enabled versions of, say, vic and vat
exist today?  Do existing apps offer automatic switchover (start
with multicast, switch to UMTP if nothing happens?)  How do they
learn about available sources&groups?

> Handovers:
> 
> ontree router is now taking place of the SSM source (or RP) in the
> example above.....follow procedure again, but with a bit in the UMTP
> header to say "handover" ....
:

> ontree UMTP capable routers may want to load balance - to this end,
> they need to exchange load information. easy. they can all do
> multicast. so

If you want any large transit providers to support this, I think 
handover/load-balancing would be key, and would have to work with 
an auxiliary router off to the side, for the following reason:

I find it very unlikely that transit providers will want to support 
the tunnel replication on their core GSR/M40/whatever routers.
So, I don't think it is worth doing unless the load-balancing/off-loading
stuff is there from the beginning.  Probably, a provider would want 
to provide the replication in an auxiliary router adjacent to an 
edge peering router.  In real hardware terms, they might park a 7200-class
router next to the peering GSR or M40 in order to support the tunnel
replication.

They would probably also control access very carefully so as not
to carry tunnels over their backbones-- only provide for tunnels
coming out to the local ISP.

So, I'm picturing a tier-1 provider putting this adjacent to their
peering router for "anISP", without any cooperation from "anISP",
and thus, sending lots of streams out the interface to "anISP".
This usage model could work, because, the Tier-1 provider could
realize a (multicast-enabled) savings in their own backbone.  
I'm just wondering what "anISP" will do when it sees N tunnels 
coming in that interface.

I'm also wondering about DoS (sometimes inadvertant, as we know) -- 
it is probably necessary for the peering router to switch-forward 
the tunnel requests to the helper box rather than having to process
them locally in any way.  Some of the new capabilities boxes have
to forward traffic differently on the basis on IP header information,
mostly developed to support web activities, might be usable for this.

> this can be used to do some balancing if we want....(how to do
> balancing is subject for further study - for example, it aint obvious
> at all:-)
> 
> now i know some Big Router Vendors might say that this is tricky to do
> in their boxes - but theres nothign to stop someone selling a
> streaming server that also peers via the IGP and then runs PIM, and
> then does this stuff.....

The problem is that all the fast core boxes are designed to separate
forwarding decisions from route and other processing, and use
some combination of distributed multi-CPU software forwarding
and/or ASIC-etc enabled hardware switching.  There is just no way
to drive a bunch of today's OC-48's and OC-192's cost-effectively
in a pure-software router.  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.

> if we don't like/support UMTP, then any other IPmc to unicast
> techniquee can also apply (fill in this form here:- [...] )
> 
> comments?

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.  Has anybody attempted
to survey the Tier-2/3 providers about what they think about
UMTP multicast vs. native multicast?


--
 Hugh LaMaster, M/S 233-21,    Email: lamaster@nas.nasa.gov
 NASA Ames Research Center     Or:    lamaster@nren.nasa.gov
 Moffett Field, CA 94035-1000  Or:    lamaster@kinkajou.arc.nasa.gov
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.