Cell Relay Archive

["ronald h. davis" <ronaldd@lucent.com>]

Jon Harley wrote:
> 
> "Chan Kok Kee" <ckokkee@singnet.com.sg> writes:
> 
> > It is difficult to implement, provision, manage and
> >most important bill.
> 
> It's easier to implement/provision/manage than UBR in that the network
> no longer has to guarantee a particular cell delay variation (CDV). I
> don't know how it's typically billed, perhaps flat rate.
> 

i don't know how you come to the conclusion that abr is easier to
provision than ubr; in ubr there is nothing that is required to be
specified while abr requires specification of the pcr, and rm cell 
rate.  neither has a cdv specification.


> > What REAL purpose does it serve when there is VBR-NRT
> >and UBR?
> 
> The very real purpose it servers is allowing providers to sell bandwidth
> twice. The first time they sell a fixed amount to someone wanting VBR,
> say. Then in all the times when that traffic isn't at its peak rate,
> they can squeeze some ABR traffic through any parts of the network
> which aren't busy, and charge the user for doing so - selling the
> same bandwidth twice. Because CDV doesn't have to be guaranteed it
> can be allowed to hang around in the less busy parts of the network
> if neccessary. The other advantage is that it's extra-efficient because
> cell loss is guaranteed to be low, unlike UBR.
> 

bandwidth is sold "twice" for both ubr and abr.  in ubr you can send
traffic without delay.  in abr, to get the qos associated with the
service there is a delay in sending a resource management cell in a
full circuit around the abr control loop.

in comparison to vbr; vbr allows traffic to be sent in peaks that
exceed the sustained cell rate, but the period of time for which
traffic may be sent at that peak rate is fixed.  abr, on the other
hand, *potentially* allowed traffic to be sent at a peak rate for
a variable amount of time.  if the end user is lucky, that amount
of time is just right to fit the profile of user traffic.  if not,
i.e. if the network rejects bandwidth increase requests, the end
user must buffer traffic until the network grants permission to
send it at a higher rate.

thus, we can see the impact of ubr versus abr on end stations.  in
abr, the network can block submitted traffic.  this puts the onus on
the end station to provide sufficient buffering to compensate for
bursts in source traffic that exceed the mcr.  furthermore, when the
network is willing to accept an increase in cell traffic from the
end station, there is a delay between the time that the network is
willing to accept the traffic, to when the end stations is informed
of this.

on the network side, the impact of buffering occurs when the network
want to withdraw previously granted bandwidth.  in this case, the
network has the responsibility for maintaining the current cell rate
until it has informed the end station that the ccr has been lowered.
thus, the network would have to maintain sufficient resources to
anticipate a ccr reduction such that it has enough time to send notice
to the end station before the network really does need to reduce the
ccr.  the problem with anticipatory cell rate modification is that if
you are too aggressive, you pull bandwidth before you really have to
do so.

the saving grace in all of this is that with abr, a clr specification
is *optional*.  one would expect low clr if the submitted traffic is
within allowable cell rate bounds.  while one would certainly have a
right to expect this much when sending traffic at a rate that doesn't
exceed the minimum cell rate, the *optional* proviso gives network
operators an "out" in that they don't have to provide guaranteed clr
under certain conditions (i.e. ccr > mcr) which relieves buffering
requirements within the network.

this reply is getting long, but i will finish by noting that an
alternative to relieving buffering burden in the network would be to
implement virtual source/virtual destination abr control loops.  this
would produce shorter control loops which can respond more quickly to
changes thereby reducing buffer requirements in both the end stations
and the network.

-- 
  __  ______  __  / __/ |       lucent technologies, naperville il, usa
_/ (_(_) / (_(_/_/_(_/  .       ronald.h.davis@lucent.com
author of "atm for public networks" published by mcgraw-hill
     http://www.amazon.com/exec/obidos/ASIN/0071344764