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

From: Jon Crowcroft <[email-masked]>
Date: Thu, 01 Mar 2001 08:34:47 +0000

In message <[email-masked]>, H
ugh LaMaster typed:

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

good question - they are the main sticking point given  a lot of tier
1 are doign native multicast

my personal intuition is that "akamizing" auto-tunneled multicast
across them is the best way

but its a zero sum game:if we succeed, they will either run native
multicast soon after, or block the tunnels.....so whatever we do, it
better be code first, and standards later (of ever)

 cheers

   jon

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 01 Mar 2001 09:18:42 -0500

Hello;

My personal feeling, based on talking with a lot of service providers, is that
they will only provide tunnel relays if they are paid to do it. The unicast
traffic that results from tunneling, of course, they will carry without
complaint. Whether paying them to do tunnel relay's
will be cheaper than just doing unicast failover (as Yahoo does now, and we
plan to do soon) is a very open question.

Inktomi sells software to "roll your own" automatic tunnels. I do
not know what level of interest they have, but they must sell some,
as they were promoting it here in SF yesterday. They call it
application layer multicast. It seems to be aimed mostly at
enterprise networks / intranets.

I still do not see how auto tunnels will scale. If my tunnel relay's will only accept a fan-out of 2,
then to serve 2048 people will require 10 generations of tunnels (and about 1000  
tunnel servers). Even
if I accept a fan-out of 5, 2048 people will require ~ 5 generations.
This seems like an awful long chain (with accumulation of jitter, packet loss, etc.) and a
lot of coordination for an actual, workable, product.(Yes, this is what the routers
do for ISM or SSM, but they are designed to do it. They also tend to cost a lot more than
I suspect people want to spend for tunnel relay's.) 

BTW, in conversations with Matt Schmitt (Yahoo/Broadcast.com multicast guy)
I found out that, while interested in SSM, they do NOT want to break ISM to
achieve it, and DO want ISM and MSDP to continue to work for the forseeable
future. He was unaware of the MSDP "black hole" situation caused by the Ramen
worm and by the adoption of SSM only domains, but he certainly did not
view it as acceptable. Their (514, as of this morning) ISM multicasts  
save them a lot of money, and will
continue at least until SSM is adopted everywhere ISM is.

Marshall

-- 

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 410
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : [email-masked]     http://www.on-the-i.com

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 01 Mar 2001 15:52:41 +0000

In message <[email-masked]>, Marshall Eubanks typed:

 >>tunnel servers). 

assume that we have the same limit roughly as with the old mbone
mrouted tunnel overlay - was fanout of 6 as far as i recall...
its still, as yo usay, a problem - in fact, the exact place you want
this (at an ACCESS ISPs dslams etc) is where you wont get it...

 cheers

   jon

i am a big fan of quantium computing - quantum computing allows n bits
to store up to 2^n values _simultaneously_ :- with quantum computing,
IP multicast becomes much simpler, and ipv6 becomes obsolete...
you can simply address all the end systems in a group using 
all their seperate IP unicast addresses, but it takes no more bits 
than a current IP header.

of course, you need a $1M MRI/interferometer in all your routers to
sort out the packet entanglement, but hey, thats today's prices;
when quantum internet addressing and routing meets optical switching 
the world will be a safer place, probably. a neat side effect of
quantum ip (quip, TM) is that we can employ schroedinger's approach to
mesage payload encoding too, which means that the fbi's carnivore
systems won't be able to decode what we've sent (well they will, but
they will have _chosen_ what to observe by observing it, so it can't
be used as evidence in court about what we did send) - feynman said it
all of course.

---

From: Dirk Ooms <[email-masked]>
Date: Thu, 01 Mar 2001 17:44:37 +0100

and we will have communication without delay by applying the EPR paradox
:-)

---

From: Hugh LaMaster <[email-masked]>
Date: Thu, 1 Mar 2001 12:05:44 -0800 (PST)

> My personal feeling, based on talking with a lot of service providers, is that
                                                      ^^^^^^^^^^^^^^^^^
I'm not sure if you are talking about Tier-1 or Tier-2/3 service providers.
I would guess that some Tier-1 providers will do this "for free" as long
as they could be sure that it would have near-zero impact on their
core/edge routers, as stated previously.  To me, that means that that
should be a way for the protocols to allow all control traffic to be
forwarded directly to the helper router without CPU intervention--
as discussed previously, when you are forwarding at OC-12/OC-48/OC-192
speeds, you need to maintain pretty strict separation of
routing processes and the switching functionality in the router.
(MSDP bursty-source encapsulation is something that violates this,
of course, so I would like to see alternatives proposed for that.)

The Tier-2/3 providers are in a different economic situation.  
So, I'm assuming that you are implying Tier-2/3 here.

> complaint.

I wonder if the Tier-2/3 providers will see it that way if they
ken how much tunnel traffic is being shoved at them.  Of course,
the traffic from N streaming video streams is the same, but,
I'm worried about the knowledge gap-- they may see it as different,
even if it isn't really.

> if I accept a fan-out of 5, 2048 people will require ~ 5 generations.

I don't think it *will* scale.  That is impossible, actually.
But, it might scale up just well enough to provide an incentive 
for Tier-2/3 providers to turn on multicast.  I'm agnostic
on that particular point.  I think the fanout you can get 
from a mid-size router can be much more that you state, though.
I know that you can do replication for 10-20 tunnels on a 
midsize software-forwarded router -- the limiting factor is 
the total outbound traffic -- that is, how large are the 
streams?  Once this is up and running, there would be an 
incentive for the downstream Tier-2/3 provider to turn on 
multicast and save 20-30 Mbits/s traffic incoming.  The 
incentive for the Tier-1 provider would be that by intercepting 
the requests at the edge, they would save the same amount 
of traffic over their backbones, so they get that immediate
benefit, plus, the long-term benefit of eventually having
the Tier-2/3 provider turn on native multicast.

> do for ISM or SSM, but they are designed to do it. 

                                They also tend to cost a lot more than
> I suspect people want to spend for tunnel relay's.) 

From the Tier-1 provider's perspective, I think this is the wrong
cost model.  The incentive for the Tier-1 provider would be to push
the traffic out to the edge; if a mid-size router can provide the
replication at the edge and save the same core bandwidth, that
potentially can save a lot of money-- possibly even enough to justify
a mid-sized router directly.  In addition, the mid-sized tunnel router
is an investment in providing strong encouragement for the downstream
provider to support multicast.

I'm still not convinced about it, mind you, but, I can see that it
could give Tier-2/3 providers the encouragement they need to implement
native multicast.

> > multicast soon after, or block the tunnels.....

Agreed.  That makes me question the effort involved, of course.
But, as stated above, it could be worth it *if* it motivates
understaffed Tier-2/3 providers to take the time to learn a little
about multicast and make the effort to turn it on.  I guess I 
don't have a good feel at this point for how Tier-2/3 providers
view multicast, and, would view this tunneling approach.

On another point: I hadn't really thought about the launcher
application also launching a tunneling process.  That is a 
good idea; it obviously works similarly for VPN client software, 
so it could probably work here, too; that way, you don't
necessarily need to modify the apps.  Putting it all in
the launcher, which is probably for its part a browser plugin,
is a good way to simplify the problem for the end user.
So, I'll concede that point.

--
 Hugh LaMaster, M/S 233-21,    Email: [email-masked]
 NASA Ames Research Center     Or:    [email-masked]
 Moffett Field, CA 94035-1000  Or:    [email-masked]
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 05 Mar 2001 13:33:59 -0800

If automatic multicast tunneling is to succeed (and thus spur the 
deployment of multicast throughout the Internet), it's important not only 
that the actual tunneling *mechanism* be automatic, but also that the 
*deployment* of this mechanism happen automatically.

What I mean by this is that if network providers (at whatever 'tier') are 
required to make an explicit decision to install new infrastructure 
specifically for multicast tunneling (e.g., tunneling relays, anycast 
routes, etc.), then it's unlikely that many of them will make the effort to 
do this.  (As Marshall Eubanks noted, most of them wouldn't install this 
unless they got paid to do so - but if you're going to pay providers to do 
something, you might as well pay them to turn on native multicast; that's 
what broadcast.com did.  In any case, we should never lose sight of the 
fact that one of the promises of multicast is the 'democratizing' effect 
that it has on content providers - even content providers with limited 
means should be able to reach arbitrary-sized audiences.)

Instead, the best way to deploy multicast tunneling is to have this happen 
automatically as providers upgrade their routers to support 
multicast.  I.e., when a provider makes a decision to upgrade his routers, 
he can know that he's also getting support multicast tunneling (so that 
remaining legacy, non-multicast-capable routers below him can also 
participate in multicast).  Of course, the provider can always disable the 
tunneling functionality (or tweak parameters such as max fan-out) if he 
wishes.  But they should not be required to install anything separate to 
make tunneling happen.

This is one of the key facets of the "URI" proposal (aka. "UDP router 
intercept"; draft-finlayson-mboned-autotunneling-00.txt).  Assuming that 
SSM becomes as popular as many people hope, many providers will be wanting 
to upgrader their routers to support SSM.  It would be great if they could 
automatically get tunneling support at the same time.

Focusing on SSM rather than ISM (at least at first) makes the 'tunnel 
endpoint location' problem easier.  In the "URI" proposal, you don't need 
any separate tunnel location mechanism (or infrastructure).  Instead, a 
tunnel endpoint ('slave') is found automatically by the JOIN_GROUP message 
sent from the end node towards the SSM source.  (This is the 'router 
intercept' mechanism; the challenge, of course, will be to see if routers 
can implement this efficiently.)

In contrast, I worry about how easy it would be to deploy schemes that 
require a separate 'tunnel endpoint location' mechanism.  In particular, 
the "AMT" draft (Thaler at al) proposes using "anycast" to find tunnel 
endpoints.  However, do we expect anycast to be widely available - even by 
users of J. Random Non-Multicast-Connected ISPs?  Aren't some providers 
likely to filter out anycast routes (because of the length of their 'prefix')?

         Ross.