Subject: Serious impact for muliticast usage?

From: IMAI Yuji <[email-masked]>
Date: Fri, 25 Jun 1999 02:03:02 +0900

Hi,

   I'm new-comer of this area, now studying about the scalability of
multicast routing, and considered how scalability effect on usage of
multicast application.

   SOLA et al described in the paper at INET'98
(http://noc.aic.net/inet98/6d/6d_3.htm) that # of state for multicast
routing at each router has O(g) even if best possible situation. (g is
number of multicast groups that run on the router.)

   I have read that there were hard discussion on this ML, whether
aggregation of multicast routing table is possible or not. Someone did
not give up and believe possibility of aggregation but couldn't find
out how to. (Ohta-san and Sola-san must be sigh again :-)

   For the present, to provide multicast service for customer, ISP
must arrange their border router that enables to hold O(g) multicast
route entries and to handle O(g) control packets, I think.

  It means that ISP must carefully choose which multicast application
to be provided.

  If ISP decide to start a tie-up with Satellite TV (like DirecTV), g
must become several hundreds. To provide video conference service on
the Internet,(ex. www.sprinticc.com) I think they must manage several
thousands of group addresses. In such amount of groups, these may be a
acceptable usage for ISP, because customers may accept pay-per-system
for such kind of special applications.

  Now, imagine the situation that AOL purchases CU-seeme and integrate
it into ICQ using multicast.

  - They "frequently" join and prune.
  - They runs it on very sparse environment.
  - User pays for AOL not for ISP, or fee-free with banner advertisement.

Can national-ISP hold several ten thousands of group entry on border
routers for such purpose in profitable manner?

  I think they couldn't, because it is comparable to the number of
full route entry on typical IXs (40000 ~ 45000).
(http://www.merit.edu/ipma/trends/) and join/prune requests beat a
router seriously. ISP operators hate a instability route very much.

Then questions,

- Is there any techniques to aggregate a multicast routing table?
  I overlooked them? Is it impossible at all?
  (I think it impossible on my heart, but look forward a miracle.)

- If no way exists to aggregate, I had better give up to use multicast
  delivery for casual video-chat frames. Is that right?

-----
IMAI Yuji

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jun 99 13:31:59 JST

Imai-san;

> Someone did

It's a political problem. Such people should be confined in some
political forum such as Internet2.

> route entries and to handle O(g) control packets, I think.

Yup.

>   It means that ISP must carefully choose which multicast application

ISPs, instead, should carefully choose routers with a lot of routing
table entries.

>   (I think it impossible on my heart, but look forward a miracle.)

:-)

>   delivery for casual video-chat frames. Is that right?

Wrong.

Aggregation of QoS-assured unicast is impossible, too, anyway.

It, instead, is trivially easy to have routers with thousands of
elementary forwarding engines, millions of synthesized forwarding
table entries and thousands of join/prune/RSVPng processor.

						Masataka Ohta