[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reacting to previous messages
David R. Cheriton writes:
> In that vein, I hope some devil advocate ISP rep. stands up and
> calls us idiots because:
> i) (as I argued before), most supposed multicast can be done with
> multiple unicast, and with bandwidth going up, even more can.
> And who wants it any way, Pointcast reborn? Recall what happened
> to the Web "push" fad - Good morning?
> ii) multicast just saves the customer bandwidth/cost while leaving
> the ISP with a charging and delivery problem.
> ii) multicast complicates running a network, a lot.
> iv) after 15 years of IP multicast not going anywhere, perhaps we
> are just to invested in multicast to recognize it as empirically
> proven to be just one bad idea. Is there other
> ideas that have been around this long, gone virtually no place,
> and we still think are good ideas?
> ....
> I think we should try to have some good answers to these challenges.
>
> DRC
Well, since you asked for a devil's advocate...
The attached mail thread occurred on the nanog mailing list in
February of last year, with Vadim Antonov, ex- "ISP rep," arguing that
IP multicast is too hard to implement, manage, and deploy, and is not
required by applications, anyway:
http://www.cctec.com/maillists/nanog/historical/9802/msg00513.html
I don't agree with everything Vadim said, and I think we can answer
many or even most of his concerns. Nonetheless, I think Vadim's
arguments deserve consideration, and they highlight the importance of
trying to identify and focus on the applications for which multicast
is really most compelling and for which unicast is not a viable
alternative.
-Hugh
----------------------------------------------------------------
To: "Sean M. Doran" <smd@clock.org>, nanog@merit.edu
Subject: Re: RA/RV Feeds from RBN
From: Vadim Antonov <avg@pluris.com>
Date: Mon, 16 Feb 1998 16:22:45 -0800
Organization: Pluris Inc.
References: <9399.199802112344@sunf10.rd.bbc.co.uk> <ytwwew2ytj.fsf@cesium.cloc
k.org>
Sender: owner-nanog@merit.edu
Sean M. Doran wrote:
> The real problem is that IPv4 Multicast scales badly with
> the number of groups, and Multicast routing is difficult.
> If you doubt any of this, kindly review the recent Dave
> Meyer presentations at any of your favourite conferences.
The _real_ problem is that the very concept of IP multicasting
is brain-dead. A multicast-based production service is neither
implementable, nor needed. Here are my reasons for concluding
so:
1) Multicast routing is not scalable and _cannot be_ scalable.
There are three distinct ways to do IP-level multicasting:
a) the most broken one: flooding multicast routing information
all over the network. Equivalent to host routing to source hosts.
b) on-demand spanning tree, like that used in EXPRESS multicasting
as developed by David Cheriton's students. That requires every
gateway carrying multicast packets to keep track of all transit mc
channels. Equivalent complexity-wise to virtual circuit-based networking.
c) sparse spanning tree, with state kept only in replicating gatways,
like that described in a TRAP draft. This has the best scaling properties
,
but replicating is very likely to occur at exchange points for the majority
of channels - i.e. the exchange-point gateways will still have to keep
the significant amounts of per-flow state.
Any multicasting sheme makes routing dependent on user-supplied
routing information. This is a major operational nightmare. Just imagine
what happens if some bozo starts injecting streams of Join-s and Leave-s.
This all means that multicasting is ok only as a nice toy. When you try to
make it available to "masses" you end up with serious routing problem.
2) IP multicasting represents a major security problem since anyone can
produce major avalanches of bogons by sending them down the existing
multicast trees.
3) Not all links are created similar. A multicast stream suitable for a T-1 d
oes
not fit into 28.8 modem connection. It means that multiple different-rate str
eams
have to be transmitted simultaneously to accomodate different conditions.
4) There is no good way to make IP-level multicasting congestion control-frien
dly.
Any provider brave enough to let multicasting into his backbone w/o strict ra
te
controls is asking for a serious trouble.
So much for technical feasibility of multicasting in the real-life backbones.
Now,
do we really need it?
1) There already are ubiquotus, cheap, high-bandwidth and technically feasible
multicasting delivery systems - also known as "boob tube", "idiot's box" and,
sometimes, "television".
The experience with TV illustrates that there's no shortage of transport capa
city
to large audiences; there's a shortage of quality content. Due to the techn
ical
problems, it is highly unlikely that multicasing can be used for large number
s
of small audiences (aka "oligocasting").
2) IP muticasting offers no significantly new services which could be attracti
ve to
consumers. The receiption is still simultaneous and extracting parts of it r
equire
waiting until unwanted content is skipped.
Are there any alternatives to multicasting? Yes, of course. The same servic
e
can be provided by application-level caches run by backbone ISPs. Unlike
multicasting, cacheing allows non-simultaneus usage of the material (i.e. yo
u
can imagine treating a newscast as a VCR tape - for example back up to view
the segment once again, etc). This makes "Internet TV" a completely differe
nt
medium from the multicasting TV - for example, it would kill "soundbite TV"
of
CNN style, in favour of a more detailed in-depth stories, w/o sacrificing br
eadth
or immediacy of coverage. Just compare CNN.COM and CNN on TV - their Web
site is a lot more informative.
Cacheing does not break congestion control and routing in backbones. It all
ows
network operators to have finer-grained control of their traffic. In the mo
st trivial
case, cacheing with zero-time expiration time is equivalent to multicasting
in terms
of traffic savings. On the other hand, intelligent usage of cache preloads
during
night hours would allow to reduce high-bandwidth canned-content traffic sign
ificantly
during the peak hours.
In other words - why anyone would ever need IP multicasting? I strongly sus
pect that
the whole IP multicasting hoopla is going the same way as ATM - stupid idea
propped
by enourmous expenditure of research and development resources, ultimately d
iscarded
in favour of more conservative and demonstrably working technology.
--vadim
----------------------------------------------------------------
To: avg@pluris.com (Vadim Antonov)
Subject: Re: RA/RV Feeds from RBN
From: Tony Li <tli@juniper.net>
Date: 17 Feb 1998 02:16:43 -0800
cc: nanog@merit.edu
In-Reply-To: avg@pluris.com's message of 17 Feb 98 00:22:45 GMT
References: <9399.199802112344@sunf10.rd.bbc.co.uk> <34E8D854.6121EC9C@pluris.c
om>
Sender: owner-nanog@merit.edu
Vadim,
I sympathize with all of your cogent comments when applied to multicasting
in the large. However, multicasting in the small, as practiced by certain
ISPs seems to violate all of your assumptions and thus violates your
conclusions. A specific example is UUcast. Comments?
Tony
----------------------------------------------------------------
To: Tony Li <tli@juniper.net>, nanog@merit.edu
Subject: Re: RA/RV Feeds from RBN
From: Vadim Antonov <avg@pluris.com>
Date: Tue, 17 Feb 1998 14:00:54 -0800
Organization: Pluris Inc.
References: <9399.199802112344@sunf10.rd.bbc.co.uk> <34E8D854.6121EC9C@pluris.c
om> <82u39yilis.fsf@chimp.juniper.net>
Sender: owner-nanog@merit.edu
Tony Li wrote:
> Vadim,
>
> I sympathize with all of your cogent comments when applied to multicasting
> in the large. However, multicasting in the small, as practiced by certain
> ISPs seems to violate all of your assumptions and thus violates your
> conclusions. A specific example is UUcast. Comments?
There's always niche applications. It is still silly to build a significant ch
unkof complexity into the core network just to carry insignificant amount of
traffic.
Tunnels are our friends.
--vadim
PS I do not see how isolated network violates "all assumptions". And i fail
to see why the same functionality (and a lot more) couldn't be implem
ented
in application-level host-based caches/mcast servers.
There's no particular reason to drag these functions into core gateway
s.
----------------------------------------------------------------
To: avg@pluris.com
Subject: Re: RA/RV Feeds from RBN
From: Tony Li <tli@juniper.net>
Date: Tue, 17 Feb 1998 14:40:21 -0800 (PST)
CC: nanog@merit.edu
In-reply-to: <34EA0896.37F75CAE@pluris.com> (message from Vadim Antonov on Tue,
17 Feb 1998 14:00:54 -0800)
Sender: owner-nanog@merit.edu
| > I sympathize with all of your cogent comments when applied to multicasting
| > in the large. However, multicasting in the small, as practiced by certain
| > ISPs seems to violate all of your assumptions and thus violates your
| > conclusions. A specific example is UUcast. Comments?
|
| There's always niche applications.
Agreed.
| It is still silly to build a significant chunkof complexity into the
| core network just to carry insignificant amount of traffic.
Ok, it's not clear to me that a niche application implies that the amount
of traffic is insignificant. If UUnet decides to deliver live real-time
CNN to all desktops in all of their customers, that IMHO might be
significant.
| PS I do not see how isolated network violates "all assumptions".
For example, you assumed (implicitly) that arbitrary systems could become
mcast sources. Clearly the UUnet model does not allow this. This makes
the problem tractable.
| And i fail to see why the same functionality (and a lot more)
| couldn't be implemented in application-level host-based
| caches/mcast servers. There's no particular reason to drag these
| functions into core gateways.
Once again, if the traffic volume is significant, there would be a
significant bandwidth savings.
Tony
----------------------------------------------------------------
To: nanog@merit.edu
Subject: Re: RA/RV Feeds from RBN
From: Michael Dillon <michael@memra.com>
Date: Tue, 17 Feb 1998 14:36:47 -0800 (PST)
In-Reply-To: <34EA0896.37F75CAE@pluris.com>
Organization: Memra Software Inc.
Sender: owner-nanog@merit.edu
On Tue, 17 Feb 1998, Vadim Antonov wrote:
> PS I do not see how isolated network violates "all assumptions". And
> fail to see why the same functionality (and a lot more) couldn't be
> implemented in application-level host-based caches/mcast servers.
>
> There's no particular reason to drag these functions into core gateways.
Those of you interested in this kind of thing will probably want to read
the article entitled Cache and Carry Internet at http://www.boardwatch.com
--
Michael Dillon - Internet & ISP Consulting
http://www.memra.com - E-mail: michael@memra.com