Subject: Auto-tunnel Rant

From: Marshall Eubanks <[email-masked]>
Date: Thu, 22 Mar 2001 01:51:35 -0500

Hello All;

  Today there was no time in the MBONED meeting to have a general
discussion of the various auto-tunneling proposals, which
was unfortunate. I will therefore inflict what I would have
said there upon on the list. I should say that I have respect for all
of the authors of these proposals, and (although I might have
specific problems with aspects of each) I have no doubt that they
could be made to work, given sufficient time and effort. My comments
are not a reflection on the technical, but instead the business, aspects
of these proposals. I also recognized that there also might be
specific applications where auto-tunneling could be useful - I am
specifically responding to the proposals to emulate SSM, which is intended
to assist broadcast.

   I think that the promotion of auto-tunnels for the purpose of
furthering multicast deployment is WRONG. It is, IMHO, NOT productive to 
expend time and effort in this direction. It diverts resources from the real goal,
which is multicast deployment. If deployed, it will cause problems that will
be inevitably be blamed on multicast. Furthermore,
I know of NO broadcaster who is requesting it. From a broadcast standpoint, 
unicast fail-over is much preferable to auto-tunnels - it is more under the 
broadcasters control, and almost certain to be cheaper - and unicast failover 
is too expensive to be easily profitable. It will also take time (6 months ? a year ? two ?) 
to implement any tunnel scheme, and I can easily see ISP's putting multicast
off to wait and see on the auto-tunnel deployment. For all of these reasons 
I sincerely hope that neither the SSM nor the MBONED group back any of these 
proposed tunnel schemes.

                                   Regards
                                   Marshall Eubanks

   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: George Michaelson <[email-masked]>
Date: Fri, 23 Mar 2001 00:44:22 +1000

I believe large amounts of edge network will *never* be multicast enabled
because the clue density drops as you approach the edge.

So without this feature, end-users in 2 or 3 subtier networks will be
unable to link back to core multicast meshes.

Surely your arguments apply just as equally to the proliferation of
auto-discovery of unicast route/path methods embedded in the applications?

And, while s/w developers may have less motivation, content *hosters* have
to scale backend platforms for large amounts of parallel feed knowing that
they could reduce their copy cycle to a fraction if they had effective fanout.

Watching two people in the same cubicle connect to the same service and
listen to the same source on a 2 second lag from each other tends to
re-inforce a view there is a role for a simple lightweight tunnel method.

You might as well rant against SSH enabled VPN and Cisco GRE at the same
time.

cheers
	-George

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 22 Mar 2001 15:50:35 +0000

>>because the clue density drops as you approach the edge.

i would ameliorate this comment - as edge nets have lans (e.g. dsl
access via ether not usb) edge sites might well have multicast but be
one hop removed from the core, but with no applciatio nlevel box
between them and coree multicast capable nets.

 cheers

   jon

---

From: Bill Nickless <[email-masked]>
Date: Thu, 22 Mar 2001 11:17:17 -0600

-----BEGIN PGP SIGNED MESSAGE-----

At 01:51 AM 3/22/2001 -0500, Marshall Eubanks wrote:
>expend time and effort in this direction. It diverts resources from the 
>real goal, which is multicast deployment. If deployed, it will cause 
>problems that will be inevitably be blamed on multicast.

As I've been playing Multicast Bully, one of the hardest things I've had to 
do is to get people who think they've got a working multicast deployment to 
fix it.  (Fix it means MSDP/PIM-SM/MBGP).  These are usually people who 
have a DVMRP tunnel off to a service provider.  I've also seen situations 
where an organization has their service provider run a PIM RP.

Adding another set of non-BCP multicast deployment options using these 
auto-tunneling procedures will inevitably increase the problem space.  I'm 
already having to ask people why their MSDP SA advertisements are coming 
from an RP in an unrelated university in another state (probably because of 
old dense mode connections).

If we need tunnels to get around broken service providers, let's do them 
explicitly so that we know where they are and can take them out when clues 
get appropriately spread out.
===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 22 Mar 2001 12:23:26 -0500

> get appropriately spread out.

Bill;

Keep up the good work. I appreciate it.

Just to clear things up, 
I have nothing against tunnels per se - use, have 'em, will sell you one.
Its putting a lot of effort into auto-tunnels that I do not regard as a good idea.

> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
> 
> iQCVAwUBOroznKwgm7ipJDXBAQF5mQP/bzFA6JtxA3S1EgMlNCjDglOCjQTSTWNl
> BS+WOU1VWM0YWwTYYi+WyTV9yeapaHBrESk4eCYbqi+9DHKVxNqemPcWM+91+hwB
> wL1zvdeQHhxY5hnPgfv+DabpAVctSDrI9+jUHtfWuzUMwn5rCOH5FNPczbL/26a+
> 4g6IRVYpGRA=
> =p0yN
> -----END PGP SIGNATURE-----

-- 

                                   Regards
                                   Marshall Eubanks

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Mar 2001 09:51:54 -0800

> between them and coree multicast capable nets.

Point not taken:

If the network administrator is able and willing to update his last-hop-router
to do not only multicast but also the tunnel-trick, why shouldn't he want
to deploy multicast throughout his network in the first place ? 

If necessary he would just do a tunnel-transit on his networks exit router
towards the Internet. That is just one tunnel, and we are doing this
for over 10 years now. If that model isn't working for someone, than why the
heck should something copletely new with maybe a bit less of configuration ???
(hey, you still have to get the tunnel box working somehow, even if you 
don't have to configure the remote tunnel endpoint adress!)

I think the tunnel solution that we don't have is one where the PC user
can easily take the initiative to get things going, but given that it would
be possible for an ISP to offer this today with some amount of initial
work, i wonder if we just don't have it because ISPs do not want to offer
this:

If let's say a Tier1 ISP wants to offer a multicast service down to Tier2/Tier3
customers that don't have contiguous IP Multicast connectivity because their
intermediate ISPs don't provide it: Why does that ISP not try to get
a dialin service provisioned based on some large-enough dial-in router
he puts someplace in his core with for example L2TP tunnels with Radius
authentication and appropriate access-lists managed from some web-server via
a CGI script that will create accounts for users whose IP source addresses are
verified to come from the ISPs downstream tiers, and which also passes some
windows install script down to the PC to configure the L2TP tunnel on the
windows PC.

Ok, so i haven't tried to sit down to check out all loose ends here, but
it seems to me as if this would all just be a question of packaging for
available components together with some level of web programming
(and maybe, uhm.. some bug fixing in components).

Sure, it's ugly in the eyes of the IETF snob, but it could be a 
"one-click solution for the user to get IP multicast", and certainly faster
to realize than solutions depending on development of completely new protocols.
Those completely new protocols in my view can just be an outgrowth, trying
to improve on such a solution (or similar ones) where necessary. Thus, if such
a solution isn't even tried to be deployed, then why would it be commercially
viable to improve on it ? Uglyness was never an important factor for commercial
success or failure in networking (yeah, we need fashion-networking, that's it!).

Cheers
	Toerless

P.S.: "ameliorate" - cool ;-))

---

From: Jared Mauch <[email-masked]>
Date: Thu, 22 Mar 2001 14:23:36 -0500

> Its putting a lot of effort into auto-tunnels that I do not regard as a good idea.

	I must also agree.  I like the idea of the tunnels in
theory but in practice I have a lot of concerns in running a network
that supports multicast.  We have native multicast (almost) everywhere
and available to customers.  I do not like the idea of my routers
doing auto tunnels across my customers network to their downstream
customer.  They need to be educated and become more savvy in their
operations.

	I think that instead of putting effort into auto-tunnels that
more time should be spent working on educating the community.  The problem
is that people associate multicast with dvmrp and mbone which is
problematic.  They remember having a 10M dvmrp link and don't understand
that pim sm+msdp+ssm don't have that dramatic bandiwdth downside.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: "John M. Zwiebel" <[email-masked]>
Date: Thu, 22 Mar 2001 12:05:15 -0800

2cents:

IMHO, the auto-tunnels should be taken care of by a CDN (or layer 4-7
replicator) rather than done automatically by routers.

Most CDN folks claim they want to "avoid the congestion in the core"
Sounds nice.  

Problem is that folks on the edge may not want that information at
the same time its being offered.

The trick is to multicast it to the edge, to be cached for delivery
on demand to the user.

CDN is a tool. Multicast is a tool.  Pick the right tool for the
job.

 ^ On Thu, Mar 22, 2001 at 12:23:26PM -0500, Marshall Eubanks wrote:
 ^ > 
 ^ > 
 ^ > Bill Nickless wrote:
 ^ > > 
 ^ > > -----BEGIN PGP SIGNED MESSAGE-----
 ^ > > 
 ^ > > At 01:51 AM 3/22/2001 -0500, Marshall Eubanks wrote:
 ^ > > >    I think that the promotion of auto-tunnels for the purpose of
 ^ > > >furthering multicast deployment is WRONG. It is, IMHO, NOT productive t
    o
 ^ > > >expend time and effort in this direction. It diverts resources from the
 ^ > > >real goal, which is multicast deployment. If deployed, it will cause
 ^ > > >problems that will be inevitably be blamed on multicast.
 ^ > > 
 ^ > > As I've been playing Multicast Bully, one of the hardest things I've had
     to
 ^ > > do is to get people who think they've got a working multicast deployment
     to
 ^ > > fix it.  (Fix it means MSDP/PIM-SM/MBGP).  These are usually people who
 ^ > > have a DVMRP tunnel off to a service provider.  I've also seen situation
    s
 ^ > > where an organization has their service provider run a PIM RP.
 ^ > > 
 ^ > > Adding another set of non-BCP multicast deployment options using these
 ^ > > auto-tunneling procedures will inevitably increase the problem space.  I
    'm
 ^ > > already having to ask people why their MSDP SA advertisements are coming
 ^ > > from an RP in an unrelated university in another state (probably because
     of
 ^ > > old dense mode connections).
 ^ > > 
 ^ > > If we need tunnels to get around broken service providers, let's do them
 ^ > > explicitly so that we know where they are and can take them out when clu
    es
 ^ > > get appropriately spread out.
 ^ > 
 ^ > Bill;
 ^ > 
 ^ > Keep up the good work. I appreciate it.
 ^ > 
 ^ > Just to clear things up, 
 ^ > I have nothing against tunnels per se - use, have 'em, will sell you one.
 ^ > Its putting a lot of effort into auto-tunnels that I do not regard as a go
    od idea.
 ^ 
 ^ 
 ^ 	I must also agree.  I like the idea of the tunnels in
 ^ theory but in practice I have a lot of concerns in running a network
 ^ that supports multicast.  We have native multicast (almost) everywhere
 ^ and available to customers.  I do not like the idea of my routers
 ^ doing auto tunnels across my customers network to their downstream
 ^ customer.  They need to be educated and become more savvy in their
 ^ operations.
 ^ 
 ^ 	I think that instead of putting effort into auto-tunnels that
 ^ more time should be spent working on educating the community.  The problem
 ^ is that people associate multicast with dvmrp and mbone which is
 ^ problematic.  They remember having a 10M dvmrp link and don't understand
 ^ that pim sm+msdp+ssm don't have that dramatic bandiwdth downside.
 ^ 
 ^ 	- Jared
 ^ 
 ^ -- 
 ^ Jared Mauch  | pgp key available via finger from [email-masked]
 ^ clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

------------------------------------------------------------------------------
	John Zwiebel                       Phone: 408-526-5303
	Cisco Systems Inc.                 
	IP Multicast Group

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 22 Mar 2001 14:02:28 -0600

At 01:23 PM 3/22/01, Jared Mauch wrote:
>We have native multicast (almost) everywhere
>customer.

If your downstream ISP customers don't support native multicast (even 
though you do), then they will be multi-unicasting across your network in 
any case.  If this multi-unicasting happens to be using a tunneling 
protocol, and you just choose to ignore this, then it will make no 
difference to you.  It'll be basically the same[*] traffic either way.

However, if your downstream customers *are* using an automatic tunneling 
protocol, then you - as an upstream provider - now have the *choice* of 
reducing this traffic by inserting your own tunneling server(s) into the 
stream.  But it's your choice.  If you don't want to worry about this, then 
you don't have to do anything.

>   They need to be educated and become more savvy in their
>operations.

Yes, we all agree that this is the ideal solution.  I wish you continued 
success in educating your downstream ISP customers :-)

         Ross.

[*] This assumes that if your non-native-multicast-enabled downstream 
customers don't have multicast tunneling available, then they will just 
send/receive plain UDP unicast packets instead.  One could argue, however, 
that if they don't have the ability to do multicast tunneling, then they 
will use TCP instead, or just throw up their hands and do nothing.

This, I think, is a better argument to make regarding the possible use of 
automatic multicast tunneling by your downstream customers.  You might 
argue that multicast tunneling would lead to an increase of *UDP* traffic 
across your network, and that this might be something you decide to be 
concerned about.

         Ross.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 22 Mar 2001 18:54:20 -0500

> you don't have to do anything.

	I'd rather my customers configure native multicast as we have
this service available.  I'd like to educate my customers to the point
that they can turn on pim on their routers and avoid this tunneling.
I don't want to have my routers send tunnels to the customer network
when if they request/properly configure they can have native multicast.

> success in educating your downstream ISP customers :-)

	I think they don't know it's available, or there's not sufficent
edge demand that they are requesting multicast.

	- Jared

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Mar 2001 16:26:37 -0800

>> across your network, and that this might be something you decide to be 

    If we put auto-tunneling in the hosts, we will have a Pointcast situation
    all over again. Which is, a lot of duplicate data going over the same
    links. Which is no different than mulit-unicast. And we make no progress.

    You don't want to make networking easy for PC users, you want to make
    applications easy to use. The network plumbing should be done by skilled
    professionals, which means they are more likely to deploy tunnels correctly
    or not at all.

Dino

---

From: George Michaelson <[email-masked]>
Date: Fri, 23 Mar 2001 12:32:59 +1000

There is probably a layering violation opr encapsulated traffic fubar
but I do want to ask, why its not possible for a multicast enabled
upstream to intercept a tunnel, and just *make* the endpoint terminate there
which should (in a global multicast) do the right thing anyway.

Obviously, 'private' tunnels are just that: but if a public framework
which is acting as a 'find me a multicast' is going to tunnel over an
enabled fabric, why not tear it open there?

I can't see what the multicast-centric answer is that makes this bad

	the ISP is multicasting already: they can't object to the traffic
	class

	its traffic efficient
	
	its actually a higher QoS than the user asked for since the mesh
	will have true local scopes

So its the layer or privacy violation thats a problem?

-George

---

From: Jared Mauch <[email-masked]>
Date: Thu, 22 Mar 2001 21:57:21 -0500

My concern becomes that lets say streaming vendor X
becomes a customer of my global ip network because we support
native multicast and offer this as a service.  I am not opposed
to tunneling over equipment within my network that does not support
pim-sm, ssm, etc..  What I am opposed to is now the rest of
the non-multicast enabled internet turns my routers into
big tunneling machines to provide services across my public and
private peering links to other networks customers that do not
have multicast deployed.

	This means I may end up with hundreds of tunnels out
each peering link and increasing the burden on my routers.  This
means that I am not paid for this packet replication across the
private/public link and is now giving my customer 100x the bandwidth
for the cost of a single outgoing stream when it costs me
more than that to deliver it to other networks.  If the network
offers multicast delivering this traffic to them in an efficent
manner is acceptable.  While I wouldn't mind becoming the #1
provider, I don't want to provide tunneling across any
interprovider links that I have (that are not customers).

	Education in deploying SSM, and pim-sm multicast I think
is important in getting deployment rates higher than what they
are presently.

	These are my concerns.

	- Jared

---

From: "John M. Zwiebel" <[email-masked]>
Date: Thu, 22 Mar 2001 21:12:40 -0800

^ 
 ^  You don't want to make networking easy for PC users, you want to make
 ^  applications easy to use. The network plumbing should be done by skilled
 ^  professionals, which means they are more likely to deploy tunnels correctly
 ^  or not at all.

You mean, skilled professionals like "us"???

;->

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Mar 2001 23:10:16 -0800

>> which should (in a global multicast) do the right thing anyway.

    Because the number of tunnels cannot be bounded. Even if you configure 
    who is allowed to connect to you, as Radia indicated in her talk, you 
    still have to configure something, so it may as well be a list of tunnels.

    I was arguing for static versus dynamic tunnels at MBONED.
    
    It is extremely dangerous to abuse a router with unknown fanout. As I
    indicated in MBONED, memory sizes, switching capacity, buffer memory k
    capacity are all based on the speeds and feeds the router is designed for.
    When replication is based on the physical interfaces, you can engineer a 
    box that actually does wire-speed multicast. Once you add tunnels 
    (unbounded or an unknown number) to the equation, you lose throughput in 
    a big way.

    I also mentioned a very simple solution:

    o PCs (windows) can already do multicast over their dial-up adaptors.
    o Therefore IGMP messages can go to the dialed-up NAS device at the ISP.
    o If you configure the NAS device to GRE tunnel to existing Juniper or
      cisco boxes which reside in the multicast-capable cloud, you're done.

    Problem solved. 

    This is a lot different than asking a tier 2 or tier 3 ISP to run native
    multicast. Of course, that is what we should encourage them to do but
    the whole idea of doing tunnels at the edge of the network is to nudge
    these access ISPs to see the light of multicast. So we have to proceed
    one slow step at a time unfortunately.

    The NAS boxes don't even have to do full multicast routing. Simply forward
    IGMP reports received on an async line over the tunnel to the multicast
    configured router in the backbone.

    Doing this gets you 1-to-many source-tree based unbiqituous multicast.

    AOL, Earthlink, and UUnet, are you listening?

Dino

---

From: Pieter Liefooghe <[email-masked]>
Date: Fri, 23 Mar 2001 17:06:24 +0100

> private peering links to other networks customers that do not

Due to lack of time I was unable to present all different possible deployment
scenarios as I intended, but the CastGate architecture has a solution for you
concerns.
In the CastGate architecture, you as an ISP can deploy your own Tunnel Database
Server to enforce a local policy.
You can make sure that only YOUR customers get tunnels (....Or even only those who
have paid for it - when interfaced via Radius), you are not required to
participate in the "Global" effort! (though it would be nice ;-) )
The deployment of the Tunnel Database is very simple just indicate for which of
your own networks you want to enable tunnels (omit country entry) and install some
Tunnel Servers (possibly relay Tunnel Servers) at "strategic" locations in your
network.

This is different from the other proposals who - as described in their drafts -
have no way to enforce a policy.

In the CastGate architecture, if one tunnel end-point does not want to act as
tunnel point for a certain client, then the client can still find a tunnel
end-point located in the country or the region (so called public tunnel servers).
All other tunnel proposals - especially the AMT draft doesn't have a solution for
this because the anycast will always yield the same relay who is the "nearest".
The Auto tunnel proposal by Ross, does have a solution for this...it travels up
the path towards the sender to find a router to terminate the tunnel... but
whatever happens the traffic is anyway going to go through the downstream routers
(also the router who decided not to terminate the tunnel).

Pieter

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Fri, 23 Mar 2001 08:31:53 -0800 (PST)

> scenarios as I intended, but the CastGate architecture has a solution for you

Pieter -

Are your GateCast slides available somewhere?

Lucy E. Lynch                           Academic User Services
Computing Center                        University of Oregon
[email-masked]             (541) 346-1774
Cell: (541) 912-7998                    [email-masked]

---

From: Pieter Liefooghe <[email-masked]>
Date: Fri, 23 Mar 2001 18:11:58 +0100

> Are your GateCast slides available somewhere?

Yes,

http://www.castguide.com/IETF/IETF-liefooghe-castgate.pdf

the castgate draft can also be found at:

http://www.castguide.com/IETF/draft-liefooghe-castgate-00.txt

If you or anyone on this list has any question about it...just ask!

Pieter