The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1996-Jul> msg00083



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

Yet another multicast scalability problem

  • From: Tim Dwight <0006078043@mcimail.com>
  • Date: Thu, 18 Jul 96 08:51 EST
  • Cc: ion <ion@nexen.com>, suzuki <suzuki@nal.ntt.jp>

I would like to offer some clarifying notes regarding pt-mpt ABR.

The main point is that, although pt-mpt ABR is not officially 
standardized, implementations should exist in early '97 (perhaps sooner
in a few cases).  It is possible, however, that the nature of some
early implementations will not scale to large IP multicast clusters,
as Ohta-san concludes below.

For details (how did this happen, what will be the nature of these 
implementations,...) please read on.


In the ATM Forum's TM 4.0 specification, standardization of ABR was 
limited to pt-pt as a practical consideration, in order to complete 
the specification.  There is no doubt that it will be extended to 
pt-mpt.  There was considerable work done in this area which did not 
make the final edit of the TM specification.  All agree that it is a
solvable problem, but more than one solution exists and we did not 
reach agreement on all the details, in time to make the document's 
publication date.  Because a delay could have impacted
other 4.0 documents (signaling, P-NNI) the decision was made to include
in the TM 4.0 spec only general guidelines regarding how a pt-mpt ABR
service could be implemented.

The issues which were not agreed in time for inclusion in the 4.0 
document, related to the extent to which the service charactistics
of pt-mpt ABR could be standardized.  For example, some implementers
suggested that the rate of the sub-tree subtending from a given switch,
be the same for all branches.  This is easy to implement by "merging"
Resource Management cells and computing new rates using a 'min' function.

Others felt that this will not scale well, because in a large tree
there will at any instant be some bottleneck on some branch, and if 
the rate of all branches must be the same then all users will
be forced down to the rate of the most severe bottleneck (I was one
who felt this way, frankly).

Of course 2 implementations which disagree on the above point, could
interoperate;  just as routers with differing WFQ algorithms can 
interoperate.  But carriers such as my company, who are concerned with
the nature of the service moreso than the nature of the implementation,
were concerned that a service with such divergent charactistics would
not be viable in the market.  We argued, successfully as it turned
out, that standardization of the service charactistics of pt-mpt ABR
would be "worth the wait".


I expect 2 things.

     (1) The ATM Forum will quickly standardize the mechanisms and
         service charactistics for pt-mpt ABR.

     (2) many switch vendors will in the interim, offer implementations
         along the lines suggested in TM 4.0.  
        

Until (1) is complete, the buyer of equipment supporting pt-mpt ABR
will have to determine its service charactistics (e.g., can it support
sub-trees whose instantaneous allowed rate can vary, or does it force
all branches to the same rate), and determine whether those charactistics
will support the desired application.  Even implementations that won't
scale well can be useful for some applications, of course.


best regards,

tim

--------------------------------------------
> > UNI4.0 ABR is practically defined in the point-to-point connection
> > environment only. I think if a multicast flow in a IP subnetwork is 
> > established by ATM point-to-point connections, it wastes ATM network
> > bandwidth. Do you have good solutions for this problem?
> 
> which raises a problem of which service class we can use with best
> effort multicast traffic.
> 
> It seems to me that use of p-to-p ABR makes ATM multicast cluster
> even smaller than described in draft-armitage-ion-cluster-size-00.txt.
> 
>                                    Masataka Ohta

############################################################
# tdwight@mcimail.com                                      #
# -------------------------------------------------------- #
# Tim Dwight                    Senior Engineer            #
# MCI                                                      #
# ATM Engineering               Phone: +1 (214) 498-1484   #
# 901 International Parkway     Fax:   +1 (214) 498-1300   #
# Richardson, Texas  75081                                 #
# U.S.A.                                                   #
############################################################