Subject: RE: BOF Agenda - Multicast Last-Mile Solutions

From: Daniel Senie <[email-masked]>
Date: Mon, 07 Jul 2003 16:57:22 -0400

At 04:20 PM 7/7/2003, Manfredi, Albert E wrote:
>I think that to make IP multicast compelling, ISPs have to be convinced 
>that it's to their advantage.

That's called CUSTOMER DEMAND. Where's the killer app?

>  One important piece MIGHT be to come up with a scheme that can 
> accurately count group membership. IGMP does NOT provide such a technique 
> as of now.

ISPs will still not care about it, even if you have provided better 
accounting, unless there's a demand.

IP Multicast requires additional skills and equipment to deploy, debug and 
maintain. In the absence of applications, there's no market. The "chicken 
and egg" issue is the need to have SOME valid, required use, and a 
compelling reason for deployment. To date, that has just not existed.

In reality, there are a handful of actual ISPs you'd need to convince in 
the USA marketplace for Multicast to work. If this technology is to be used 
on the public networks, then Comcast, Charter, Time Warner, Verizon, SBC 
and a handful of others would need to get it working on their broadband 
networks. Get them, and the rest will follow. Multicast to the last mile 
only makes sense to, say Comcast, if there's a good chance of having more 
than one in 100 people watching in a neighborhood (the point at which 
multicast might save them some traffic to distribution nodes).

Multicast certainly has proven useful in private networks. In public use, I 
don't see any significant change in the availability to consumers in the 
last 7 years. 

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 Jul 2003 23:06:04 +0200

there is more traffic about multicast than actual wan multicast.
there is massively more intranet multicast use than internet.  the
reasons are that there is money in the latter and none in the
former.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 Jul 2003 23:06:04 +0200

randy

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 7 Jul 2003 22:09:19 +0100 (BST)

> reasons are that there is money in the latter and none in the

okay, there's no money in multicast.
there's no money in p2p filesharing apps.
do any p2p filesharing apps try and use multicast?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 Jul 2003 23:13:27 +0200

> there's no money in p2p filesharing apps.

two differences
  o p2p file sharing requires nothing in core
  o there is money in it for the end users
i.e. the benefit lies where the cost lies

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 Jul 2003 23:13:27 +0200

two differences

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 7 Jul 2003 22:09:19 +0100 (BST)

L.

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 08 Jul 2003 06:42:07 +0100

there is a large body of end system multicast work based on p2p infrastructures

despite some provider ideas of what customers want...

that said, core, transit and edge ip level multicast are mostly irrel. to the p2p group
comms use...the problem is not usually sender capacity efficiency, or even concurrent
reception...its more just a tool for the job

see scribe, esm, splitstream and CAN based cast papers (and s/w)

while i am all for money, i wish it would stop dominating engineering discussions...build
it well, and they will come...

 >><http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 08 Jul 2003 06:42:07 +0100

cheers

   jon

---

From: [email-masked]
Date: Tue, 8 Jul 2003 16:56:43 -0700 (PDT)

> reasons are that there is money in the latter and none in the

Good point! 

But I would have to argue that we do not know if there is money in
interdomain multicast simply because is doesn't exist on any usable
scale. The benefits of multicast intradomain are quite easily realized as
it is most often a single administrative domain - if you want it
everywhere, go turn it on.

Interdomain does not have that luxury. Its an all-or-nothing
proposition. Every router in the path (across multiple administrative
domains) must be mcast enabled or it doesn't work. So current penetration
I'd guess to be well under 10%. Even a core network which is mcast
enabled and would like to offer/sell multicast service really has nothing
to sell. Sure, their network is enabled but that really accounts for
nothing without all the other networks in the path to the receivers
(content customers) also being enabled.

Greg

---

From: [email-masked]
Date: Tue, 8 Jul 2003 16:56:43 -0700 (PDT)

Good point! 

Greg

---

From: [email-masked]
Date: Tue, 8 Jul 2003 16:59:30 -0700 (PDT)

> i.e. the benefit lies where the cost lies

Agreed! And the cost of transmitting streaming content to a large audience
via unicast is piled high on the content owner/distributor. So they can
read and understand mcast, build a biz-plan around mcast distribution, and
even turn-up mcast transit with their provider of choice - but they still
don't have any usable mcast penetration to realize the cost benefits.

There is a missing piece.

Greg

---

From: [email-masked]
Date: Tue, 8 Jul 2003 16:59:30 -0700 (PDT)

Greg

---

From: Alan Crosswell <[email-masked]>
Date: Wed, 09 Jul 2003 10:37:14 -0400

> There is a missing piece.

There are too many pieces:  Namely CDNs like Akamai freeflow streaming.
/a

---

From: Alan Crosswell <[email-masked]>
Date: Wed, 09 Jul 2003 10:37:14 -0400

---

From: [email-masked]
Date: Wed, 9 Jul 2003 10:51:41 -0700 (PDT)

> There are too many pieces:  Namely CDNs like Akamai freeflow streaming.

Too many non-standard pieces that do not leverage multicast.

Greg

---

From: [email-masked]
Date: Wed, 9 Jul 2003 10:51:41 -0700 (PDT)

Greg

---

From: Bill Nickless <[email-masked]>
Date: Fri, 11 Jul 2003 10:47:52 -0500

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

>Too many non-standard pieces that do not leverage multicast.

Is this a failure of the Akamai engineers to do the "right thing" and use 
"standard" Internet multicast?

Or is it a failure of "standard" Internet multicast to provide what Akamai 
engineers need?

Has anyone in the MBONED working group talked to the Akamai engineers and 
asked them why they didn't use standard Internet multicast 
facilities?  Have those lessons learned been incorporated into the process 
to evolve Internet multicast?  Has the solution that Akamai came up with 
been examined with an eye towards standardization?

What about other network-based group communication schemes, such as those 
popular in the supercomputing community like the Message Passing Initiative 
(MPI), Parallel Virtual Machine (PVM), and so forth?  Recall that the 
motivation for the original IP multicast work by Cheriton and Deering was 
to support the V distributed system.  Have those communities learned 
anything in the last 15-20 years that the IP community hasn't yet 
leveraged, but should?

I applaud the Multicast Last-Mile Solutions BOF, and the creation of the 
Internet Multicast Documentation, Oversight, and Coordination (IMDOC) 
function within MBONED.  I support them as steps towards a process driven 
by real world requirements, leading to innovative and successful solutions.

===
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: Bill Nickless <[email-masked]>
Date: Fri, 11 Jul 2003 10:47:52 -0500

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

===