The MPLS WG Archive

[Aimin Sang <sang@ece.utexas.edu>]

Dear David,

Thanks for your good insights regarding the overbooking factor. I have
several questions:


> Erickson Trejo-Reyes wrote:
> > 
> > By overbooking you mean that, for example, if a voice source can be
> > treated as a VBR source with 64 KB peak bit rate and activity factor
> > of 0.4, then the reservation should be made to a higher value than the
> > computed effective bandwidth (and obviously higher than the average
> > bit rate of 0.4 times 64KB)?
> 
> The idea behind overbooking is simple.  You accept requests for
> resources that you don't have.
> 
> Under certain circumstances, this is OK.  For instance:
> 
> - You know that the overbooked reservations are temporary and will go
>   away (eg. the overload is due to a failure somewhre and will be moved
>   to another switch when the rest of the network realizes this and
>   reroutes the tunnels.)
>

Could you please give us a more detailed example (when "this is OK") to
set overbooking factor? Say: The overbooked reservation is temporary
because of the re-routing, but who set the overbooking factor and how? 
It is set by the network operator from time to time, or the CAC algorithm
automatically?

Further, I guess you mean that the CAC's decision of overbooking can be
balanced by traffic engineering. If that is right, are these two control 
at the same time-scale?

Given the GCAC in PNNI 1.0, should the overbooking factor be a coeffient
of AvCR (e.g. 120% * AvCR), or of the actual allocated bandwidth (or
effective bandwidth) to each flow? By functionality, they should bring the
same effect.

Considering the highly non-stationarity of real network traffic, the
overbooking factor can hardly works well (with high utilization and low
loss) all the time. So does the overbooking factor reflect the real
"over- reservation of the bandwidth resources", or it is just a tuning
knob of the specific CAC algorithm?

 
> - You know that most of these tunnels aren't going to be running at peak
>   capacity.  This is dangerous for an ISP to assume - especially when
>   legal contracts demand a certain service level and you don't know the
>   nature of the data, but it can be acceptible in a situation where you
>   do know what kind of data will be flowing through the tunnels.
> 
This is a very good point.

> - You know that the tunnesl aren't used much during certain times of the
>   day.  For instance, many corporate links (especially those that are
>   not behind a publicly-accessible server) almost go idle at night, when
>   most employees have gone home.  Again, you have to know your customers
>   here.
> 
> > I had thought that, if an MPLS node is due to use only certain
> > percentage of its total capacity to serve, for example, guaranteed
> > services, it would not be too harmful to make reservations (up to the
> > available percentage) only based on the sustained rate, with the only
> > possible consequence of temporary squeezing the throughput of
> > best-effort services. Comments?
> 
> Squeezing best-effor services due to a lot of reservations is not
> overbooking.  That's just the nature of best-effort traffic.
> 
> Overbooking is where (for instance) a 10G switch grants an aggregate of
> 20G among all of its tunnels.  If the tunnels don't actually use more
> than 10G total, you're OK - if not, then you cause their guarantees to
> be violated.
> 
> Whether or not this is acceptible will depend on why you're overbooking
> (is it something transitory that will quickly go away, or is it a
> deliberate management decision), and what kind of service your customers
> are actually paying for.
> 

The last paragraph gave me very good insights, but I still do know how to
overbook in case of something transitory. Maybe you mean the traffic burst
which comes and goes very quickly, and the overbooking factor is just
fixed during that period.

If a local CAC gives the network operator an interface to tune the
overbooking factor, I think the corresponding tuning guideline should
follows tightly. Could you please comment on this, or give some example
about the tuning guideline?


Many thanks,

Sincerely,

Aimin
****************************************************************
                Aimin Sang, Ph.D Candidate
                Telecommunication Networks
                ENS 106, ECE Department
                Univ. of Texas at Austin

                Mailing/Home Address:
                1515 Rio Grand Dr., Apt. 723, Plano, TX 75075

                Fax:   (214)-291-2280
                Phone: (972)-943-3285 (Home)
                       (214)-291-2375 (Office)

                URL:   http://www.ece.utexas.edu/~sang

"You can never be too rich, too thin, or have too much bandwidth"
*****************************************************************