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

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 6 Jul 2003 17:20:39 -0400

Interesting subject. From what I'm told, one of the big obstacles in enabling multicast all the way through is that use of multicast reduces the revenues ISPs can expect for providing network services? That's a plausible reason. Are there others? Security?

Bert

> -----Original Message-----
> From: Greg Shepherd [mailto:[email-masked]]
> Sent: Wednesday, July 02, 2003 7:23 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: Alex Zinin; Bill Fenner; Keyur Patel; Greg Shepherd
> Subject: BOF Agenda - Multicast Last-Mile Solutions
> 
> 
> 
> Multicast Last-Mile Solutions BOF
> 
> DESCRIPTION:
> 
> Successful content distribution business plans have been 
> hampered by the
> all-or-nothing nature of a multicast routed infrastructure. 
> Several drafts
> have arisen over the past few years to address the last-mile multicast
> deployment gap, but have all lost momentum for various reasons. Recent
> efforts on yet another draft have revealed the need to have 
> all affected
> parties participate in the effort in order to provide a 
> comprehensive yet
> simple and deployable solution.
> 
> A content owner which wishes to build a buisness model around 
> multicast
> distribution is hampered by the current limited scope of multicast
> deployment. Their only option today is to purchase multicast transit
> services from their provider of choice which does not ensure the path
> between their content and their customers is multicast enabled. The
> administrative control of the multicast topology in this 
> relationship is
> restricted to the provider and the content customer. The 
> missing step on
> the path to full multicast deployment will require a solution which
> allows the content owner the benefits of multicast replication,
> independent of the radius of the multicast deployment.
> 
> The purpose of this BOF is to bring together operators, content
> providers/owners, application and protocol implementors to discuss the
> problem and worked towards a mutually desired solution. The expected
> outcome will be an evaluation of interest, a better defined problem
> statement, directions for any future progress from the BOF
> participants.
> 
> AGENDA:
> 
> 1. Agenda Bashing (all)
> 2. Problem description (shep - 10min)
> 3. Discussion of current gaps and future direction (from the floor)
> 
> WEB REFERNCE:
> http://www.shepfarm.com/multicast/last-mile
> 
> RELEVANT PAST WORK: (this list is possibly incomplete - please send
> updates)
> http://www.shepfarm.com/multicast/upim/draft-ietf-mboned-auto-
multicast-01.txt
http://www.shepfarm.com/multicast/upim/draft-finlayson-mboned-autotunneling-00.txt
http://www.shepfarm.com/multicast/upim/draft-finlayson-umtp-07.txt
http://www.shepfarm.com/multicast/upim/draft-keyur-pim-host-extensions-00.txt
http://www.shepfarm.com/multicast/upim/draft-jibiki-iwata-msdp-idmf-00.txt

MAILLIST:
http://www.shepfarm.com/mailman/listinfo/mtp

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

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

---

From: [email-masked]
Date: Mon, 7 Jul 2003 10:40:34 -0700 (PDT)

On Mon, 7 Jul 2003, David Meyer wrote:

> >> since practically no access ISPs allow multicast, how do they know it
> >> reduces revenue? 
> >> 
> >> this is a typical armchair economist argument
> 
> 	No ISP/carrier that I have ever worked for (or even, that
> 	I know of, where ISP == "IP Transport Bandwidth
> 	Provider") has ever been able to demonstrate any kind of
> 	CAPEX savings due to multicast. In fact, the places where it
> 	might be most useful (tail circuits) provide the opposite
> 	incentive to the bandwidth provider (why would I provide
> 	you a technology that allows you to buy less of my
> 	product [bandwidth]?) 

As Lenny pointed out, any 'savings' assumes canabilizing unicast content
for multicast. BUT a large-audience multicast transport service could
bring a whole new range of content at a much higher quality (read
bit-rate) which could be a completely different service to sell. Its not
about saving bandwidth in the core. Its about creating a transport service
which allows successfull biz-models/services for content owners which are
ISP customers. Having profitable customers is a good thing. 
 
> 	OTOH, perhaps that's a selling point when marketing to
> 	large content providers or the like. The reality,
> 	however, is that such custmers (and in fact, most large
> 	consumers of b/w) want carrier diverse facilities, kinda
> 	blowing away that argument in any event. Clearly there
> 	are cross-incentives here.  

Yup, I've seen the same. But I also think a large content owner wants
first the largest audience possible.

> >> obviously if all the users using simultaneous unicast switched to
> >> multicast this MIGHT be true, but the real point is that it enables
> >> new sources, applications and services, and might therefore INCREASE
> >> revenue....noone can say for sure...
> >> 
> >> i think the technical obstacles (cable tv modem head end, DSLAM, and
> >> other minimal support for igmp magic, security, charging for group
> >> size and other stuff are the critical points and think this BOG Is an
> >> althogether
> >> Most Exellent Idea
> 
> 	Yep.

Thanks for your support Dave,

Greg

> 	Dave

---

From: [email-masked]
Date: Mon, 7 Jul 2003 10:40:34 -0700 (PDT)

Greg

---

From: David Meyer <[email-masked]>
Date: Mon, 7 Jul 2003 09:40:23 -0700

>> > 	could/would/should/...As we all know, this whole
>> > 	discussion is 10+ years old. I really don't see anything
>> > 	new here.
>> 
>> Good point! ...and that is the problem. So I guess you're saying that we
>> need something new?

	What I meant is what I said. 

	Dave

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 07 Jul 2003 09:34:35 +0100

i think the technical obstacles (cable tv modem head end, DSLAM, and
other minimal support for igmp magic, security, charging for group
size and other stuff are the critical points and think this BOG Is an
althogether
Most Exellent Idea
In missive <[email-masked]
m>, "Manfredi, Albert E" typed:

 >>Interesting subject. From what I'm told, one of the big obstacles in =
 >>enabling multicast all the way through is that use of multicast reduces =
 >>the revenues ISPs can expect for providing network services? That's a =
 >>plausible reason. Are there others? Security?
 >>
 >>Bert
 >>
 >>
 >>>=20
 >>>=20
 >>>=20
 >>>=20
 >>>=20
 >>> Successful content distribution business plans have been=20
 >>> hampered by the
 >>> all-or-nothing nature of a multicast routed infrastructure.=20
 >>> Several drafts
 >>> efforts on yet another draft have revealed the need to have=20
 >>> all affected
 >>> parties participate in the effort in order to provide a=20
 >>> comprehensive yet
 >>>=20
 >>> A content owner which wishes to build a buisness model around=20
 >>> multicast
 >>> administrative control of the multicast topology in this=20
 >>> relationship is
 >>> restricted to the provider and the content customer. The=20
 >>> missing step on
 >>>=20
 >>>=20
 >>>=20
 >>>=20
 >>>=20
 >>http://www.shepfarm.com/multicast/upim/draft-finlayson-mboned-autotunneli=
 >>ng-00.txt
 >>http://www.shepfarm.com/multicast/upim/draft-keyur-pim-host-extensions-00=
 >>.txt
 >>http://www.shepfarm.com/multicast/upim/draft-jibiki-iwata-msdp-idmf-00.tx=
 >>t
 >>
 >>MAILLIST:

 cheers

   jon

---

From: Bill Nickless <[email-masked]>
Date: Mon, 07 Jul 2003 13:42:47 -0500

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

At 09:35 AM 7/7/2003 -0700, Greg Shepherd wrote:
>As I stated in the BOF overview, I would just like to describe the problem
>collectively. We can then turn to if/how it can be solved - either by
>putting together existing pieces or creating some missing piece. But we
>have to start by agreeing on the problem, AND agreeing on what a solution
>should achieve.

I won't be able to make it to Vienna.  Y'all had better take good notes!

At the risk of repeating myself, here's my take on it.  (Focusing on IPv4, 
without loss of generality to IPv6):

RFC 966 answered that question almost 20 years ago:

    Multicast has two primary uses, namely distributed binding and
    multi-destination delivery.  As a binding mechanism, multicast is a
    robust and often more efficient alternative to the use of name
    servers for finding a particular object or service when a particular
    host address is not known.  For example, in a distributed file
    system, all the file servers may be associated with one well-known
    multicast address.  To bind a file name to a particular server, a
    client sends a query packet containing the file name to the file
    server multicast address, for delivery to all the file servers.  The
    server that recognizes the file name then responds to the client,
    allowing subsequent interaction directly with that server host.  Even
    when name servers are employed, multicast can be used as the first
    step in the binding process, that is, finding a name server.

    Multi-destination delivery is useful to several applications,
    including:

       - distributed, replicated databases [6,9].

       - conferencing [11].

       - distributed parallel computation, including distributed
         gaming [2].

    Ideally, multicast transmission to a set of hosts is not more
    complicated or expensive for the sender than transmission to a single
    host.  Similarly, multicast transmission should not be more expensive
    for the networks and gateways than traversing the shortest path tree
    that connects the sending host to the hosts identified by the
    multicast address.

(Bill here again)

Bottom line:

I believe we should start with RFC 966.  RFC 1112 targets an Internet that 
no longer exists, and LAN technology that has long since been superceded.

For some time I've wanted to help write an RFC-1112-bis.  I'm very much 
looking forward to the results of this BOF.  Again--take good notes!

===
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: David Meyer <[email-masked]>
Date: Mon, 7 Jul 2003 09:24:19 -0700

>> bit-rate) which could be a completely different service to
>> sell. 

	So you are saying that you have a technology that is
	looking for a "whole new range of content at a much
	higher quality"?  OK. I don't disagree that multicast is
	a technology looking for such an application (at least in
	the inter-domain space; we all know that there are many
	enterprise applications). 

>> Its not about saving bandwidth in the core. 

	Yes. History and experience has shown us that this much
	is clear. 

>> Its about creating a transport service which allows
>> successfull biz-models/services for content owners which are 
>> ISP customers.

>> Having profitable customers is a good thing. 

	I don't think any one is arguing that profitability isn't
	a good thing (or if they were, I didn't undertstand that
	from the thread). 

>> first the largest audience possible.

	This would seem to be the case if there is a positive
	correlation between maximizing ROIC and/or minimizing
	OPEX, and audience size. It is not clear (at least not
	clear to me) that this is necessarily the case. 

>> Thanks for your support Dave,

	Sure. Hopefully we can tackle some of the thorny problems
	that have plagued multicast deployment (and have been
	pointed out in this thread).

	Dave

---

From: David Meyer <[email-masked]>
Date: Mon, 7 Jul 2003 09:40:23 -0700

Dave

---

From: David Meyer <[email-masked]>
Date: Mon, 7 Jul 2003 08:16:20 -0700

Yep.

	Dave

---

From: David Meyer <[email-masked]>
Date: Mon, 7 Jul 2003 08:16:20 -0700

Yep.

	Dave

---

From: Bill Nickless <[email-masked]>
Date: Mon, 07 Jul 2003 13:42:47 -0500

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

       - conferencing [11].

(Bill here again)

Bottom line:

===

---

From: David Meyer <[email-masked]>
Date: Mon, 7 Jul 2003 09:24:19 -0700

Dave

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 7 Jul 2003 09:35:46 -0700 (PDT)

> 	enterprise applications).

I think there are already plenting of applications. As we, the choir, have
been preaching to ourselves for years, this must be content driven in that
its the content owners who stand to benifit from a multicast transport biz
model.

Thanks,
Greg

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 7 Jul 2003 09:35:46 -0700 (PDT)

Thanks,
Greg

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 07 Jul 2003 09:34:35 +0100

cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 10 Jul 2003 09:59:06 +0100

so picking up on the _binding_ point, i see the 
last mile multicast as potentially similar to the
NAT traversal problem, especially for cases of last mile access kit
that are multicast atheistic....at least for one case 

(actually, quick aside-  its not just last mile, its last kilometer,
last foot, last meter etc - by which i mean there is a set of
solutions and we need to list all of them with their applicability,
pros and cons (e.g. acountabile, secure, performance, limits etc)

so continuing on NATTering:

given the last mile is not really a general case of a route for the
cases where mcast doesnt work, but is just a signaling problem and we
are talkign about wilful non use of igmp, then a stateful
multicast to unicast NAT solution in the router at the DSLAM or other
site is a possible one - 

of course, it also means the session advertisement (whatever mechansm
is used) must also be modified or enhanced as it flows towards edge
to include unicast - but that is often the job of newer application
aware nats anyhow, esp. if they are part of CDN stuff 
so while it entails changing a few things, the end app wouldnt have to
change at least for inbound/downlink - sending uplink from a non mast
capable link might be trickier...

and it gets a bit painful for things that use multiple ports (rtp
things) although NATs already have to comprehend that for ftp-type
apps anyhow

In missive <[email-masked]>, Bill Nickless t
yped:

 >>-----BEGIN PGP SIGNATURE-----
 >>Version: PGP 8.0.2
 >>
 >>iQCVAwUBPwm/K6wgm7ipJDXBAQHURgP+KHN5kuwgZFPMIRUNIsaPPINZzPd+Q2v2
 >>3aPtB9YfIadNW9Ia0ENaH3X06+uwfVA6VK5ZPFLqJQh4K6Bh4yrggpzWYhxclDio
 >>aNYkJsPHXzGoCUbiEzdLF4eg40mxR2DA0t5WzjwOAwMKqudvVJWyIvHcuRP04LgU
 >>RXWZsj013Zs=
 >>=37Vd
 >>-----END PGP SIGNATURE-----
 >>
 >>

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 10 Jul 2003 09:59:06 +0100

cheers

   jon