Subject: Multicast

From: Ali Boudani <[email-masked]>
Date: Wed, 07 Mar 2001 11:24:11 +0100

Hello,
First the CBT protocol was created to use shared tree solutions because
DVMRP and the other dense mode protocols werent scalable. there were
many problems with CBT (which is bidirectional) so PIM-SM was cretaed
which provide some switching (between shared tree and source tree). and
after that there is some discussions about the bidirectional PIM, which
is like CBT.
Are we in circle here or what ??

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 07 Mar 2001 10:30:40 +0000

>>Are we in circle here or what ??
 
not really. the mainstream current multicast action is concentrating on
 single source (and on single source reliable multicast transport)
since we didn't feel we understood all the complications of ANY of the
multiple source schemes for IP or reliable....(e.g. interdomain
routing, and multiple source semantics for reliable) - 

there were'nt really "problems" with CBT apart from we never managed
to get a router vendor to committ to an implmenetation which we could
deploy and learn from - tony ballardie got a lot of the details out,
but the two implementaions i know of never saw light of day.....bidir
pim is cool, bgmp is cool, but action in implementation/details/spec
is waiting on getting the PIM SSM stuff completely shaken down....

its all part of a good learning experience and (as any good s/w
engineer might say) its the norm:-)

 cheers

   jon

---

From: Ali Boudani <[email-masked]>
Date: Wed, 07 Mar 2001 11:35:46 +0100

Hello again,

Isnt SSM just a particular case of PIM??
It is the specifications for just specific sources but they arent adressing
the multicast in general.
am I right ?

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 07 Mar 2001 11:10:46 +0000

>>Isnt SSM just a particular case of PIM??

the right place for this discussion is
  SSM <[email-masked]>, 

SSM is a subset of PIM SM, roughly, and relies (sort of) on IGMPv3 (at
least on a subset of equiv. functionality).

 >>the multicast in general.

not quite - i dont think the whole IETF list is the right place for
this one - see
http://www.ietf.org/html.charters/ssm-charter.html

i think since the ssm work is close to done, we'll see work resume on
bidir (s/cbt/pim-bidir:-) soon , and similalrly in the RMT work
see
http://www.ietf.org/html.charters/rmt-charter.html
a lot of building blocks are close to done (prob. about a year) then
we'll see some work on multiple source (the latent demand for multiple
source applications is imho underestimated, but until we can fix the
more immediate problems with supporting 1-many, we can't really expect
people to deploy many-to-many extensively- other problems being
addressed are concerned with having good solutions for multicast security (see 
http://www.ietf.org/html.charters/msec-charter.html
and for many-to-many, for congestion control (to meet transport area
requirements)....

i think (but of course i am usually wrong) that we may see progress on
this in 2002...

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 7 Mar 2001 21:25:44 +0859 ()

Ali;

> Are we in circle here or what ??

If there were some progress somewhere, you might be able say "circle".

But, in IETF, no proposal makes any sense that there is absolutely
no movement.

Here, you are on a point behind a start line.

SSM is no different.

The real difficulty of multicast is in the various relationships
to resource reservation.

I've heard that ISPs, which were expecting to receive special charge
for multicast service, are now bitterly recognizing one aspect of the
relationship that, even if multicast is free, customers do not bother
to use multicast if they pay flat rate to receive any amount of unicast
traffic

Those serving the customers simply increase the number of capacity
of servers, of course.

						Masataka Ohta

---

From: Ali Boudani <[email-masked]>
Date: Wed, 07 Mar 2001 15:07:17 +0100

Hello,
are you suggesting that there is no multicast problem :-)
and that is the ordinary unicast problems related to ressource reservation
and by expanding the capacity of servers and also of the link bandwidth that
problem will be solved. :-)

thanx

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 7 Mar 2001 23:29:31 +0859 ()

Ali;

> are you suggesting that there is no multicast problem :-)

There is none remaining.

> problem will be solved. :-)

I'm saying it was simple and easy to solve the resource reservation
and multicast problems at once (www.real-internet.org).

You can see that RSVP has a fatal flaw trying to accomodate all the
possible and impossible multicast protocols.

Another interesting aspect of the relationship is that each
multicast group consumes a precious resource of routing table
entry that multicast is a resource reserving communication.

							Masataka Ohta

---

From: Brad Huntting <[email-masked]>
Date: Wed, 07 Mar 2001 08:45:00 -0700

> The real difficulty of multicast is in the various relationships

This is so completely wrong...

Multicast is cheaper than unicast from every resource perspective.
It uses fewer network resources for both content providers and
consumers.  It even uses fewer resources for network providers.

"The real difficulty of multicast" is that it's much more difficult
for ISP's (and presumably router venders) to support than unicast.

brad

---

From: Ali Boudani <[email-masked]>
Date: Wed, 07 Mar 2001 16:45:29 +0100

> > are you suggesting that there is no multicast problem :-)

Well, what about scalability, and the interoperability with the underlying unicast
protocols. and what about the interdomain multicast???

> and multicast problems at once (www.real-internet.org).

Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English)
or there is another one??
I didnt found it in the internet-drafts at the IETF !!!

thanx

---

From: Katsushi Kobayashi <[email-masked]>
Date: Thu, 08 Mar 2001 01:06:21 +0900

Ohta san,

ISP talking with you intend to charge whether sender, reciever
or both ?　I guess some ISP would not like to start multicast
service, even if subscriber request it. They might sometimes
say as an excuse what you heard.

I think there are a lot of way to make a special charge for special
service without resource reservation protocol as you think, even
if you say "It is not scalable way" :)

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 8 Mar 2001 01:03:28 +0859 ()

Ali;

> Well, what about scalability,

Which scalability?

In a sense, multicast is proven not to scale that aggregation of
multicast routing table entries is impossible, which is why
it is a resource reserved communication.

Income scales proportional to the number of groups that
you can afford larger routing table.

> and the interoperability with the underlying unicast
> protocols.

The current underlying unicast protocols are best effort and irrelevant.

> and what about the interdomain multicast???

Huh?

It is crazy to first design a intra domain protocol with a lot
of scalability problems and expect an interdomain protocol
magically fix the problems.

Protocols should just work.

Please don't say interdomain policy control by BGP. BGP is for
best effort policy.

> or there is another one??

There are several. Some of them are available in Japanese only, I think.

> I didnt found it in the internet-drafts at the IETF !!!

I think it was not posted at all.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 8 Mar 2001 01:19:16 +0859 ()

Kobayashi san;

> if you say "It is not scalable way" :)

You completely miss the point.

Because best effort service is flat rated, receivers are not motivated
to use multicast. Senders learned to have more servers. See my column
article on the most recent IPSJ magazine for details.

That's all.

							Masataka Ohta

---

From: Rick Irving <[email-masked]>
Date: Wed, 07 Mar 2001 16:00:23 -0500

> consumers.  It even uses fewer resources for network providers.

Flaw: You are defining network resources as being circuit bandwidth.

> for ISP's (and presumably router venders) to support than unicast.

   No, the real difficulty is it consumes massive amounts of 
"network resources"... the rare ones.

  ;)