Subject: reduction over unicast

From: [email-masked] (Mike O'Dell)
Date: Sun, 3 Aug 1997 11:02:02 -0400 (EDT)

multicast does NOT really reduce the load - it merely makes it hard to find
(it also trades link bandwidth for routing bandwidth, and that's a very
bad tradoff)

in the unicast case, the station sourcing the load pays for 
the privilege to do that proportionally to the impact on the infrastructure.
if the site injects a zillion unicasts simultaneously, they pay for that
capability.

in the multicast case, a small subscriber can produce significant
impact across the entire network and there is no way to ascribe the
work done by the network to the instigator of the work.

remember i'm worried about significant scale - >>100,000 recipients
of a group

	-mo

---

From: Karl Auerbach <[email-masked]>
Date: Sun, 3 Aug 1997 11:22:52 -0700 (PDT)

> (it also trades link bandwidth for routing bandwidth,...

I haven't observed that following a multicast distribution tree is all
that difficult, nor have I empirically observed any level of routing
traffic that is even within orders of magnitude of the data traffic.  And
my arithmetic indicates that when one tallys the number of packets carried
on each link, multicast wins by a large margin in nearly all cases.

I know you have good reasons for what you say, I just don't understand
them.
 
> work done by the network to the instigator of the work.

I consider "the instigator" in a multicast session to be the person who
tunes into the group and says "send me the traffic".  If nobody is
listening, the data is effectively quenched near or at the sender.

Flood and prune multicast routing clearly has bad characteristics when
deployed in a big way (and often even when deployed in a small way.)  But
that particular implementation shouldn't cause condemnation of IP
multicast any more than the bad characterists of RIP should cause
condemnation of unicast IP.

> remember i'm worried about significant scale - >>100,000 recipients

In those big groups the savings due to multicast are most likely to be at
their maximum.

When the group is small and the clients are on widely divergent arms of
the network then the benefits are not likely to be as great.

		--karl--

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 06 Aug 1997 18:35:16 -0500

> work done by the network to the instigator of the work.

I still claim it's an error to think of multicast traffic as
belonging to, or being caused by, the sender.  Charge it to the
receivers and the economics become more sensible.

Scaling the routing, well, that's a different story.

				Matt

---

From: George Michaelson <[email-masked]>
Date: Thu, 07 Aug 1997 09:58:32 +1000

Problem: senders are identifyable. Receivers are harder to find.

Instance: we bill using Netflow information from cisco. We do this
	  at the border routers: bigger boxes which can run netflow
	  and have the cycles to do the UDP dataflow.

	  at the border, the recipients inside your billing cloud are
	  unbounded. To bill them we need (a) flowtags and (b) a way
	  to sample or measure the bytecost which can be correlated
	  as a time-series against all other billable listeners in your
	  cloud to make it a 'fair' price. Clearly if 10 start off listening
	  or interacting the cost is 1/10th of the pool but if 8 drop off
	  then the 2 parties left share the can for the remainder?

Its hard. Simpler to average multicast dataflow over long baseline and
charge a b/w rental but right now, the margin is with usage base charges
fine-grained, and thats a worldwide trend: even the UK academic networks
are moving towards it and here in OZ uni's bill down to some bloody fine
grain levels.

Now I read the MCI/Progressive announcement as a slow deathknell for n-way
interactive, and a resurgeance of 1-way unidirectional broadcast comms
layered onto multicast for traffic efficiency: In that model, charging
the injector of the noise is MUCH simpler and MUCH nicer (to me :-)

Somebody needs to show me how we can do sane and FAIR usage based multicast
billing on recipients. If they do, I will take it *right* to the table
for us to try a real service here.

Mind you, maybe I should sit on this. Isn't it a thesis topic for somebody
with an interest in Economics?

---

From: Scott Huddle <[email-masked]>
Date: Wed, 06 Aug 1997 20:28:13 -0400

The direction of charging is immaterial.  You can do it either
or both ways, remember that you can have charging schemes that
are in-band (pay your ISP to send or recieve) or out-of-band
(e.g. receiver gives his credit card to pay the "postage" to the
sender).

-scott