The IP Over NBMA (ION) Archive

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



[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: Fri, 19 Jul 96 01:34 EST
  • Cc: mohta <mohta@necom830.hpcl.titech.ac.jp>, ion <ion@nexen.com>, suzuki <suzuki@nal.ntt.jp>

>> 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.
>
>From the best effort IP multicast point of view, if, among
>1,000 receivers, 999 can accept 6Mbps and 1 can't accept
>more than 64Kbps, what should the rate of the sender be?
>What if, it's 800 vs 200? If it's not a sender but an
>intermediate router at the edge of ATM network, what can
>it do?
>
>The answer, I think, is, it depends on the application and the
>sender controls everything.
>
>So, while ATM forum may have it's own policy of bandwidth
>management, any bandwidth control suggested by the network
>is not useful for IP.


I think that's a rather sweeping statement.  Is control over loss
probability not useful to IP?

I think pt-mpt ABR can be useful for IP, but I agree with your concern
about the non-usefulness (or non-scalability, anyway) of any service 
which constrains the throughput of the multicast tree according to the
rate of the slowest branch.  I hope it was clear from my previous mail,
that I do not believe this to be a necessary charactistic of pt-mpt ABR.
I only meant to say that due to the incomplete standardization, some
early implementations may "get away with" such behaviour.

I think it may be difficult to have a productive discussion of this
subject, until either the specification is clarified (so that the 
required service characteristics are clear) or we have experience with
actual implementations.


best regards,

tim


############################################################
# 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.                                                   #
############################################################