The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1996-Sep> msg00131



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Unicast inscalability of NHRP

  • From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
  • Date: Tue, 24 Sep 96 15:16:01 JST
  • Cc: mohta@necom830.hpcl.titech.ac.jp, ion@nexen.com

Eric;

> > Eric, can you say "scalability"? If it's 20% and you have 5 times
> > more hosts, it's now 100%.
> >
> 
> Yeah! And your Math dresses you funny too!  But seriously, you're still
> missing my point(s).  If you assume that a significant portion of the 
> hosts are within the "large cloud" (as I did in my example),

No, I don't assume such a thing.

Even Joel hoped that only 10% of all the Internet is ATM (not
necessarily a single cloud).

But, if you assume almost all the Internet is on a single ATM cloud,
it's OK.

Then, multicast inscalability of cut-through assures that the ATM
network consists from CSRs with no global Q.2931 signaling for IP.

So, with your example, there is no reason to have NHRP.

> If the cloud gets larger both the number of participants and the available
> resources increase (hence the room large enough for a million).

The problem is that the number of VCs is the most limiting
resource.

> But, as I said before, the
> fact that the cloud got larger does not mean that any NBMA sation is going
> to communicate with other NBMA stations much more than it did before

So?

It has nothing to do with the VC bottoleneck at the egress router.

> So, the way I do my math, the number of VCs required by each NBMA station
> for unicast conversation stays relatively constant.

So, the number of VCs at the egress router linearly increases, which
is the unicast scalability issue.

Q.E.D.

> Even if the total of
> all other data transfer did increase at a rate proportional to the number
> of other stations in the NBMA - AND this amounted to 20 % in the original
> configuration - then increasing the cloud size by a factor of five would
> increase the portion of other data transfer to about 56 % (5/9).  Almost
> half of all data transfer would still be supportable via shortcuts.

I can't follow your logic or assumptions or reasoning like "other
data transfer", "20 % in the original configuratin" or "56 % (5/9)".

Though I don't know how is your assumption on the number of host
(10 hosts each having 500 connections?) with your unfounded 20%
case, if 5 times more is not enough, feel free to increase the
number of hosts 10 or 100 times more.

The bottom line is that unicast NHRP is not scalable.

							Masataka Ohta