Subject: Re: packet loss between mbone2.UU.Net & SanFrancisco.mci.net

From: [email-masked]
Date: Tue, 11 Feb 1997 11:12:33 -0800 (PST)

|> "Dorian R. Kim" <[email-masked]> wrote:
|> 
|> Hear, hear! A "Global Multicast Internet" faces four fundamental hurdles:

:

|>         4) A business model that ISPs can use. Billing by the size of the 
|> pipe doesn't cut it.

"Doesn't cut it" *compared to what*?

Not obvious.  Consider that billing by the size of the pipe is equivalent
to billing by the maximum bandwidth you allow a user to use.  Sure, it
would be nice for the user if the peak-to-average ratio could be 
increased, since, with a direct high-speed connection, this ratio,
peak-to-average, is usually quite high.  But, at what cost can users 
be billed for a combination of actual usage and size of pipe?  
If it costs 10X per packet to provide this capability, I would 
prefer a pipe 10X bigger.   And, what about other costs, such as 
the costs associated with maintaining (unicast and maybe DIS-related 
multicast) routes?  And iss there an efficient way to charge for 
"packets received", where "efficient" is defined (by me) to mean, 
"low cost of billing for the packet relative to the cost of delivering it"?

You may not be aware of it, but, in some cases, public utilities have
discussed billing customers by the ratings of their service panels,
not by KWH.  Some people complain bitterly about a company even 
making such proposals, but, the power company has large fixed costs
associated with generating capacity that is only used on the hottest
summer day of the year.  The question you have to ask yourself is, 
"What are the real marginal costs associated with usage?"  There is
no moral issue involved in making people pay for "actual usage" if
it is cheaper to provide better service without such billing.
[I guess this is why economists are rarely politicians  ;-)  ].

  Hugh LaMaster, M/S 258-5,     Email:       Please send ASCII documents to:
  NASA Ames Research Center     Internet:    [email-masked]
  Moffett Field, CA 94035-1000  Or:          [email-masked] 
  Phone:  415/604-1056          Disclaimer:  Unofficial, personal *opinion*.

---

From: Henry Kilmer <[email-masked]>
Date: Tue, 11 Feb 1997 18:07:46 -0500 (EST)

>"low cost of billing for the packet relative to the cost of delivering it"?

I can fill my T1 with unicast packets and only a T1's worth of
bandwidth will cross my ISP's backbone.  If I send a T1's wor
h of
multicast packets, and my service provider is doing the replicating,
then so long as there are listeners, I can generate a great deal more
backbone bandwidth than what my T1 can support.  The current billing
structure in the ISP environment does not take this into account.

-Hank

---

From: "Carl Malamud [IMS]" <[email-masked]>
Date: Tue, 11 Feb 1997 21:15:34 -0500 (EST)

> bandwidth will cross my ISP's backbone.  If I send a T1's worth of

Not true.  Take the example of UUNET which has installed a
multicast infrastructure.  Let's assume you're a UUNET customer.
You send a T1 of multicast packets to two types of users:

	1) users who have UUNET as an ISP
	2) users who have another ISP

For case 1, you have used your entire T1.  UUNET charges you.
The recipients of your traffic have also used their entire
T1's.  UUNET has charged each of them.

For case 2, you send a single T1 of traffic out, which stays
as a single T1 until it hits the edge of UUNET.  As far as
they're concerned, this is no different than if you were to
do a ftp session with somebody outside of their network.

Of course, if UUNET peers with several other service providers
in different locations, their multicast tree will split and
you are using T1 onto their national backbone, then split
out into the peering points, but if there is enough of that
traffic, they simply reengineer their backbone.

An ISP charges based on the size of the peak pipe into
your facility and on your average utilization.  If they've
done multicast right, they don't particular care if you
generate multicast or unicast packets.  In fact, in the
case of internal customers, they get to sell the multicast
traffic several times.  

Carl

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 12 Feb 1997 10:05:01 +0000

>structure in the ISP environment does not take this into account.
 
with PRUNING, yo ucannot

receivers can ask to receive that group -if they have T1, each one of
them can fill up their T1, but that means they don't do anything else,
and you STILL don't send any more than a T1's worth....

a set of multicvast flows in use by n senders and m receivers will
generate less traffic hotspots than a set of unicast flows to m
receivers by a factor of m....simple as that

(except your routes need to be able to the packet replication at the
branch points....)

all this ISP fear and loathing of multicast is compeltely wrongheaded,
and based in the  expierence with people running REFLECTORS for things
like CUSEEME which run OUTSIDE the ISPs control, and DO result in
traffic multiplication.....multicast in your backbone
is a traffic DIVIDOR when implemented right.

sure a receiver can join 10 groups, all being sent at T1, but they
still only get to pull down the traffic on the branch point from the
backbone to them - and if the backbone couldn't handle the 10 T1
senders to their seperate (typically disjoint) groups, it isn't 
really a backbone, its an under-engineered, over re-sold ripoff:-)

the problems with multicast that ISPs ligetimately complain about have
been listed nicely by the UUNET people - lack of
debugging tools, inter-domain routing, QoS routing....

billing is not one of the problem

you might as well argue about billing for web caches
[actually, people do - e.g. in new zealand, where they've thought
about it - using a cachhe, as with using multicast, should REDUCE the
bill for an information user.....)

cheers

 jon

---

From: "Brian O'Shea" <[email-masked]>
Date: Wed, 12 Feb 1997 19:25:17 -0500

-all this ISP fear and loathing of multicast is compeltely wrongheaded,
-and based in the  expierence with people running REFLECTORS for things
-like CUSEEME which run OUTSIDE the ISPs control, and DO result in
-traffic multiplication.....multicast in your backbone
-is a traffic DIVIDOR when implemented right.

OUCH!!  This is an aside from the main topic, but we have to defend ourselves!!!

////////////////	Soap box ON	/////////////////////////

Yes, the majority of CUSEEME/REFLECTOR traffic is simple duplication of
streams using unicast, but it's not our fault!  We have the ability to do
multicast group conferencing in the 2.1 reflector, and the 2.1 clients.  The
reflector createst the groups, and sends out an SDP session announcement, and
the clients can join.

The problem with having a multicast only reflector is that if you connect to
the reflector and there are 20 users sending video you'll get 20 streams, at
god knows how much data!!!!  Also, since a certain well know operating system
couldn't even implement IGMP 2 so you could leave groups, and a number of
ethernet cards for those platforms only support 3 multicast groups before
becoming confused, we couldn't use our alternate plan of using a different
multicast group for each video sender.  And that mode was only attempted
because source pruning, which is the real solution, is not available in said
operating system, nor any other commercially available OS that I know of.

So, we allow both unicast and multicast connections to the reflector.  You can
mix modes where LAN based clients, or those that have the bandwidth, can join
with multicast, and the 28.8 users can connect with unicast.  Then the
reflector will only forward to the unicast user the video of the person or
persons that they choose to watch.  Conversly the video stream of the 28.8
user, if any, will be forwarded to the multicast group, if any of the
multicast users are watching.  Also, any other unicast users will receive the
video of other unicast users, based on whether they are watching or not.

AND you can LINK reflectors together to optimize bandwidth utilization by
placing reflectors at either end of a pipe between, probably, intranet LAN's
and the streams will only travel through that pipe once, and will either be
replicated, or multicast, at the other side, in both directions.

So, we're not unaware of the large amount of traffic that our products
produce, and we're doing our best to provide intelligent, leading edge
solutions to mimimize our bandwidth utilization, among other things.

 ////////////////	Soap box OFF	/////////////////////////

And that's all I have to say about that. :-)

-bos

+***********************************************************************+
+ Brian O'Shea					White Pine Software	+
+ Reflector Group Leader			542 Amherst St		+
+ [email-masked]					Nashua NH, 03063	+
+ Phone: 603-886-9050				Fax: 603-886-9051	+
+		All it takes is all you've got.				+
+***********************************************************************+

---

From: Petri Helenius <[email-masked]>
Date: Thu, 13 Feb 1997 08:56:26 +0200 (EET)

> solutions to mimimize our bandwidth utilization, among other things.
A small detailed question...

Will the reflectors talk to each other using multicast and can the
reflectors 'prune off' traffic that they don't have any clients to?

Pete

---

From: "Brian O'Shea" <[email-masked]>
Date: Thu, 13 Feb 1997 08:57:06 -0500

-Brian O'Shea writes:
- > AND you can LINK reflectors together to optimize bandwidth utilization by
- > placing reflectors at either end of a pipe between, probably, intranet LAN's
- > and the streams will only travel through that pipe once, and will either be
- > replicated, or multicast, at the other side, in both directions.
- > 
- > So, we're not unaware of the large amount of traffic that our products
- > produce, and we're doing our best to provide intelligent, leading edge
- > solutions to mimimize our bandwidth utilization, among other things.
- > 
-A small detailed question...
-
-Will the reflectors talk to each other using multicast 

Yes, they did it before the clients could.  I'd like to take credit for it,
but the origina source we got from Cornell had ref-ref multicast
capabilities.

-and can the
-reflectors 'prune off' traffic that they don't have any clients to?

I'm not sure what you're asking, but I'll give an example that might help.

Two reflectors, East and West.  With clients connected to each e's and w's.

If none of the w's are watching any of the e's, none of the VIDEO data from
the e's gets sent to the west reflector.  As soon as a w start's watching the
video of an e, that video gets forwarded to west.  If a second w starts
watching that same e, the video is still only sent once from east to west.

If you wanted to add a third "Peer" reflector the logical choice would be to
link them together using a single multicast group.

Hope that helps.  BTW, you can get demo versions of the reflectors and clients
for free if you want to check it all out. 

	http://www.wpine.com

-bos

---

From: Karl Auerbach <[email-masked]>
Date: Thu, 13 Feb 1997 12:31:41 -0800 (PST)

> reflectors 'prune off' traffic that they don't have any clients to?

I was also kinda wondering whether the reflectors could move themselves to
reside at the optimal branch points in a distribution tree.  ;-)

It seems to me that "reflectors" are an application-specific multicast,
application layer router of sorts that does a proprietary analog to sparse
mode. 

That's not a bad thing in itself if one has but one application. 

And to the extent that the topology of the reflectors is in not in accord
with the physical topology there is going to be a degree of inefficiency. 

(Of course the same concern about topology dissonence can be made about
the mrouter topology.)

			--karl--