Subject: RE: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)?

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 10 Jul 2003 16:04:47 -0400

Curtis Villamizar wrote:

> The topic of counting leaf nodes came up.  For a tier-1 provider, it
> is sufficient and perhaps more relevant to know only the number of
> exit points from that provider that a sender is reaching.  How much
> branching occurs beyond the tier-1 provider is inconsequential to the
> tier-1 provider.

Is this necessarily enough? For example, wouldn't a sender want an accurate count of his audience, sort of like Nielsen ratings, only a real count instead of statistical sampling? And couldn't a provider use that count as the basis for charging the sender? I'm not sure what business models are in use now, so I might be off base.

> The good news is that collection this information is
> something that can be confined to the single provider if protocol
> support existed to do so.  From the provider's business standpoint, it
> may be sufficient to limit bandwidth and this bounds (number of exit
> points to the provider) for lower service levels including any default
> (comes without charge or a fixed extra) flat rate service and offer a
> higher service level in which the sender bandwidth and exit point
> count limits are set higher.  This would allow flat rate low usage
> multicast such as small conferencing but still provide the means to
> generate revenues appropriate to higher bandwidth and wider spread
> multicast, such as VOD.

That, and more. I seem to recall, for example, that on 9/11/01, not only was I unable to get *any* news source via streaming media from my office, due to network congestion caused in large measure by all those TCP/IP-based streaming media sessions, but the various streaming media outlets were proud of supporting in the low hundreds of thousands of sessions that entire day(!). But that's peanuts, isn't it? I doubt broadcasters would be proud of such low numbers on that day. Multiple millions would be more like it.

I would expect that use of the right protocol here would give the network providers the revenues they need (want) while at the same time providing a level of service that is somewhat more competitive with the broadcast alternatives.

Bert

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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Jul 2003 17:06:03 -0400

In message <[email-masked]
m>, "Manfredi, Albert E" writes:
> Is this necessarily enough? For example, wouldn't a sender want an accurate c
> ount of his audience, sort of like Nielsen ratings, only a real count instead
>  of statistical sampling? And couldn't a provider use that count as the basis
>  for charging the sender? I'm not sure what business models are in use now, s
> o I might be off base.

If you are a content provider then yes.  If you are a provider of
connectivity and want to milk the billing on multicast service for as
much as you possibly can even if it doesn't cost you anything for
expansion of the groups beyond your borders then yes, but that
mentality yields low to zero service penetration.  This is sort of
like the X.25 per packet billing vs IP flat rate only with multicast.
X.25 certainly still has the advantage in terms of ability to bill per
packet - its also dead.

> That, and more. I seem to recall, for example, that on 9/11/01, not only was 
> I unable to get *any* news source via streaming media from my office, due to 
> network congestion caused in large measure by all those TCP/IP-based streamin
> g media sessions, but the various streaming media outlets were proud of suppo
> rting in the low hundreds of thousands of sessions that entire day(!). But th
> at's peanuts, isn't it? I doubt broadcasters would be proud of such low numbe
> rs on that day. Multiple millions would be more like it.

For the tier-1 IP provider a few thousand access routers are reached
with multicast and how many CPE routers is reached doesn't matter
because the end customer already foots that bill.  This is an example
where multicast would have done some good.

> I would expect that use of the right protocol here would give the network pro
> viders the revenues they need (want) while at the same time providing a level
>  of service that is somewhat more competitive with the broadcast alternatives
> .
> 
> Bert

For the most part the protocols exist.  Attempts to make it a big
revenue source and bill too much for it has so far killed it for some
providers.  For the market penetration that existed at the time, it
was cheaper for the source (content provider) to get a big pipe and
unicast.  Commercial multicast has existed for a long time.

The goal should be to provide some means to insure the transport
provider doesn't take a loss due to high bandwidth wide distribution
multicast, and that limited distribution multicast can be offerred
unmetered if not free with the unicast service.  Make it cost
effective for end users (senders and receivers) and multicast
penetration will occur.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Jul 2003 17:06:03 -0400

Curtis