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

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

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

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 7 Jul 2003 07:23:28 -0700 (PDT)

On Mon, 7 Jul 2003, Manfredi, Albert E wrote:

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

Not really.  It's usually the first thing that (uninformed) ISP product
managers come up with, but on the list of reasons why mcast isn't deployed
everywhere, the unicast-revenue-cannibalizing argument is fairly far down
on the list.

This argument would make more sense if there actually was unicast traffic
that mcast could cannibalize.  We are talking mainly about video here, and
for all practical purposes, there really is no video of any kind of
critical mass on the Internet today.  The reason is simple- there's no
business plan that could support unicast video.  Anyone who tried to do it
is now out of business or just gave up after realizing that you are just
throwing money away if you want to do video over unicast.

As Jon pointed out, the reality is that mcast traffic would be NEW content
that is not currently possible/viable with unicast, rather than traffic
that's available via unicast but transported more efficiently than
unicast.  New traffic on the network means hopefully new revenue, so your
unicast content and revenue stays constant, while mcast simply augments
it.

-Lenny

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 7 Jul 2003 07:23:28 -0700 (PDT)

-) Jon Crowcroft wrote:
-)

-Lenny

---

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

> everywhere, the unicast-revenue-cannibalizing argument is fairly far down

That's really a billing problem, not a multicast problem. You just
explain to the ISP that they can charge multiple customers for the
same multicast packet, but that their accounting systems need work to
do that properly.

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

L.

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

---

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

L.

---

From: Bill Nickless <[email-masked]>
Date: Mon, 07 Jul 2003 14:10:34 -0500

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

>  constrained capacity, multicast increases, not decreases, your

Exactly right.  I ran into an example of that recently.

Check out Nanometrics Seismological Instruments.  They market satellite 
networks of seismometers.

    http://www.nanometrics.ca/products/naqs.htm

Nanometrics uses UDP/IP over multicast for transport of data across the 
satellite channel.  It's a slick setup.  From that web page:

    NAQS Server has all the hooks to support large network
    configurations in mission critical installations. NAQS
    Server supports UDP/IP multicast. This permits fully independent
    installations to operate concurrently, simultaneously processing
    data from the same remote stations.

    With two or more NAQS Server systems operating in parallel,
    customers can migrate system configuration changes and software
    updates from a secondary test installation to the primary NAQS
    Server system. This approach to system administration effectively
    eliminates system down time due to incorrect configuration.

Nanometrics' big selling point is how efficiently they use the space 
segment bandwidth for a seismological sensor network.  Their example:

    Nanometrics recommends allocation 6.6kbps for a typical 3 channel
    100sps seismograph station. This provides the bandwidth required
    for continuous first-difference compressed data, error-correction
    retransmission and protocol overheads. A single carrier of 112 kbps
    can support 17 such channels: 16 remotes and 1 central hub. Libra
    can efficiently support networks of any number of remotes by
    configuring data rates and adding carriers as needed.

    Intelsat, which operates satellites around the world, publishes
    $5800 per year as their standard tariff rate for a five year, 100
    kHz Ku-Band spot beam lease.  If a network consists of 16 remotes,
    the monthly operating cost of each is $30.

(Disclosure statement: I'm not connected with Nanometrics in any way, 
either as an investor, customer, or vendor.  I sat through one of their 
presentations a few weeks ago and was positively impressed.)

===
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 14:10:34 -0500

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

===