Date: Mon, 11 Sep 2000 16:14:42 -0700 (PDT) From: Mike Leber <mleber@he.net> Sender: owner-nanog@merit.edu
Currently MAE-ATM customers can only create what amounts to CBR PVCs to other peers by using a web interface called PeerMaker. This means that you must allocate a fraction of the capacity of your port to each of your peers which typically results in PVC sizes betweem 5 amd 10 Mbps if you have an OC3 port. Due the the configuration of the MAE-ATM switches, any traffic sent in excess of the configured PVC size is dropped (we have verified this repeatedly). This results in a large amount of wasted capacity and unecessary droppage of packets. Traffic tends to grow and shift; continual reconfiguration of PVCs is not realistic.
By comparison, Pac Bell NAP and Ameritech NAP customers talk via wirespeed UBR PVCs, which generally results in better utilization of the service. Better in this case being measured by larger amounts of traffic being carried with less loss and less management cost.
The benefit of using UBR vs CBR at an exchange for most users is based on the premis of connections not being saturated. Even in the case of a saturated connection CBR does not fix things; in fact it creates another bottleneck with a much lower saturation threshold.
To further clarify things, Worldcom does not use CBR at the MAEs. It uses ABR. And ABR would be ideal if Worldcom used it as it was designed. The parameters for ABR are peak cell rate (PCR) and minimum cell rate (MCR). Bandwidth is reserved for the MCR and it is guaranteed to be available. Between MCR and PCR traffic is passed on a best-effort basis and is treated exactly like UBR traffic. So ABR would seem ideal for a MAE. You have a specified amount of reserved to provide for reliable access for contractual obligations and everything else works if the bandwidth is available just as if it was UBR. The only real problem is that the MAEs limit PCR to twice MCR. This simply wastes resources. PCR should be set to the minimum line speed of to two lines. If the PCR was set to this value, things would be much better. I would actually prefer this to UBR since UBR has no guarantees. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634