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: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 7 Jul 2003 10:04:41 -0400

Jon Crowcroft wrote:

> since practically no access ISPs allow multicast, how do they know it
> reduces revenue? 
> 
> this is a typical armchair economist argument

But I suspect it's the major obstacle in its deployment.

We've implemented RFC 1112/2236 quite successfully, and it's pretty much the only way to go, when using IP for *control system* communications. Problem is, commercial gear that supports multicast is not all that plentiful. Like firewalls, for example. Seems to be "ooops, you didn't say multicast."

> 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

Agreed. Determining group size, btw, is itself not so easy to do, since membership need not be announced if another member has already multicast his join report to the router. Maybe an accurate method for determining group size will be an important topic?

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 7 Jul 2003 14:48:15 -0400

Greg Shepherd wrote:

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

Sounds like digital TV (DTV) over the Internet. That would seem like a no-brainer to me too, but it isn't a no-brainer to the ISPs if they think they can make more revenues by using INefficient means of transport. That's been the problem all along. For non-commercial applications, no argument at all. Multicast is often the only sensible answer. Add reliable transport to UDP multicast, like RFCs 2357, 2887, 3048, and 3453, and its usefulness is self evident even for other than streaming media traffic.

> Its not
> about saving bandwidth in the core.

I guess I'm missing this part. Why is not saving bandwidth in the core important as well? Take DTV distribution as the example. I would think that you'd set up a multicast with its scope limited to a TV market size, so as not to infringe on the TV affiliates in other markets. The routers inside this area would need to dedicate a lot less bandwidth to DTV streams if they could create multicast trees instead of unicast streams to each edge router, no?

> But I also think a large content owner wants
> first the largest audience possible.

I agree, for the content provider. Not necessarily for the distribution system provider. He simply wants the highest revenues for distributing the product.

You'd either need to convince the ISPs that they can profitably distribute content with multicast that would be unprofitable with unicast, or you'd need a killer app that MUST use multicast.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 7 Jul 2003 14:48:15 -0400

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 7 Jul 2003 15:25:08 -0400

> At 07:54 PM 7/7/2003 +0100, Lloyd Wood wrote:
> >(multicast makes a lot of sense in a satellite broadcast environment,
> >  where link utilisation matters. If you can resell your
> >  constrained capacity, multicast increases, not decreases, your
> >  revenue.)
> 
> Exactly right.  I ran into an example of that recently.

Sorry, but I had exactly the opposite reaction.

Over a broadcast channel, such as satellite, it seems to me, any sort of encapsulation is just fine. At the receiving end*s*, the receivers can easily reformat the packet to be unicast or multicast, to enable the appropriate routing where routing matters.

The broadcast channel's individual streams can be differentiated in any number of ways, including the use of Class D addresses certainly. But that makes a weak argument for IP Multicast, I think. For instance, what's wrong with using PIDs in MPEG-2 Transport Stream? Or what about differentiating based only on a LLC/SNAP header ID?

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 7 Jul 2003 16:20:52 -0400

Lloyd Wood wrote:

> Manfredi, Albert E wrote:
>
> > My fundamental disagreement with bringing up a broadcast channel is
> > that the broadcast channel per se couldn't care less.
> 
> the terminals receiving from that channel, however, do care when
> discriminating. Channels are fundamentally physical, they don't care.
> A shared link medium is, however, a different beast.

Okay, maybe we need examples to stay on the same page. Greg Shepherd mentioned high bit rate streams as a good reason to use IP multicast vs unicast. So let's take satellite DTV distribution as an example.

The head end uplinks DTV program streams to the satellite. They come back as MPEG streams, identified by a physical channel and a PID within that channel. So far, NO indication of multicast anything. Just unique IDs for each bitstream, so they can be differentiated at the receiving ends.

Now this signal can be immediately decoded and used by a satellite receiver, or it can be encapsulated in IP Multicast packet, then in an Ethernet frame, for distribution over a wired internet of some kind. The broadcast link does not make for an interesting "must have" for IP multicast, in this TV example.

Okay, forget TV. If the satellite link is a more intrinsic part of this internet, i.e. a leg in an otherwise routed IP network, then use of IP multicast in this particular leg of the network is not really any more or less compelling than transmitting IP multicast packets over a wired link. Could be Ethernet, could be a wave-divided optical link, could be a SONET STS frame, could be a T3 or T1 phone link.

I think that to make IP multicast compelling, ISPs have to be convinced that it's to their advantage. 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.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 7 Jul 2003 15:40:47 -0400

Lloyd Wood wrote:

> > Over a broadcast channel, such as satellite, it seems to me, any
> > sort of encapsulation is just fine. At the receiving end*s*, the
> > receivers can easily reformat the packet to be unicast or multicast,
> > to enable the appropriate routing where routing matters.
> 
> what do you mean by 'reformat the packet'?

Reincapsulate the frame that was broadcast over the broadcast medium. That frame can be used by multiple systems, presumably, only one of which would need to worry about IP routing, multicast or otherwise.

> > The broadcast channel's individual streams can be differentiated in
> > any number of ways, including the use of Class D addresses
> > certainly. But that makes a weak argument for IP Multicast, I think.
> > For instance, what's wrong with using PIDs in MPEG-2 Transport
> > Stream? Or what about differentiating based only on a LLC/SNAP
> > header ID?
> 
> You'd have to indicate that the multicast packet was a multicast
> packet via PID or LLC/SNAP _as well_ - tightly coupling semantics down
> the layers.

My fundamental disagreement with bringing up a broadcast channel is that the broadcast channel per se couldn't care less. There are no difficult routing decisions to be made in the satellite or other broadcast link. The broadcast channel is the equivalent of a single Ethernet link along the way, in a wired internet.

Bert

---

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.

---

From: Bill Nickless <[email-masked]>
Date: Mon, 07 Jul 2003 16:54:28 -0500

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

At 04:20 PM 7/7/2003 -0400, Manfredi, Albert E wrote:
>that it's to their advantage. 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.

In the context of RFC 966, that's an excellent criticism.

Recall that the work described in RFC 966 was originally 
designed/implemented to support the V distributed system on a Metcalfe 
Ethernet.  Quoting:

    On a philosophical point, there has been considerable reluctance to
    make open use of multicast on local networks because it was
    network-specific and not provided across the Internet.  We were
    originally of that school.  However, we recognized that our "hidden"
    uses of multicast in the V distributed system were essential unless
    we resorted to dramatically poorer solutions - wired-in addresses.
    We also recognized, as described in this paper, that an adequate
    multicast facility for the Internet was feasible.  As a consequence,
    we now argue that multicast is an important and basic facility to
    provide in local networks and internetworks.

In the context of a Metcalfe Ethernet supporting a distributed system, 
group membership operations can be entirely contained in the host.  Each 
host merely discards data on the shared bus that is not addressed to them, 
or the Host Group addresses for which they have no interested processes.

In the context of multicast flooding between Metcalfe Ethernets, the 
requirement is to discover where there is zero vs. one (or more) Host Group 
Members on the subnet.  IGMPv1/2 were designed to meet this requirement.

In the context of today's IEEE 802 networks, with full-duplex links 
supporting a single host on each IEEE 802.1 bridge port, additional group 
membership information is required.  IGMP snooping/spoofing attempts to 
discover the set of IEEE 802.1 bridged segments with interested receiver(s).

My position on IGMP snooping/spoofing is probably clear to all.  :-)

But to address your point, I agree that we should look at more 
sophisticated group management techniques--at the link layer and the 
internetwork layer.

At the risk of repeating myself, the IP over Infiniband and IP over IEEE 
1394 (Firewire) specifications do a much better job of multicast group 
membership management than is commonly done on IEEE 802 networks today.

===
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: Mon, 07 Jul 2003 16:54:28 -0500

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

===