The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Yet another multicast scalability problem
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. #
############################################################
|
|