The MPLS WG Archive

[Anoop Ghanwani <anoop@cosinecom.com>]

Title: RE: Fw: MPLS and CAC

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, August 29, 2000 11:09 AM
> To: mpls@UU.NET
> Subject: Re: Fw: MPLS and CAC
>
>
> Kireeti Kompella wrote:
> >
> > While we are on the subject of overbooking, let me point out two
> > things:
> >    a) it makes sense to traffic engineer best effort IP traffic,
> >       and assign it a bandwidth parameter (a point that I believe
> >       Curtis mentioned, but I'm speaking from memory);
> >    b) persistent overbooking is fairly common.
> > (a) is a common reason for (b).
> >
> > One scenario for (b) is where you have bursty traffic (happens a lot
> > with IP): say that some traffic trunk averages 40Mbps, but peaks to
> > 70Mbps.  You could put two of these on a 100Mbps link, and
> most of the
> > time, you are just fine.  If the two trunks peak at the
> same time, you
> > have some dropped traffic, but on the whole, you come out ahead
> > (modulo the SLAs with your customers).
> >
> > You may not want to do this with your Gold customers, but for best
> > effort IP, this should work just fine.
>
> In the ATM world, you can signal this kind of bursty traffic with
> VBR-style reservations.  Where you can guarantee a certain level, and
> allow for intermittent spikes above that level.
>
> Can this be signalled by RSVP as well?  The two IntServ reservation
> styles (guaranteed service and controlled-load) don't seem to provide
> for this.  If they really can't signal it, then perhaps it would make
> sense for someone to propose a new standard service in the IntServ
> working group.  (If one of the two existing styles is capable of
> signalling this, then forget my suggestion.)
>
> It seems to me that if you have an LSP where you know the
> traffic to be
> bursty (average 40M, spiking to 70M), it would make more
> sense to signal
> these characteristics, instead of trying to determine bandwidth and
> overbooking parameters to get the same effect.

By signaling these (I know CR-LDP allows you to do it, and I think
RSVP does as well), the problem only gets pushed to a later stage
in the process... at some time, the request needs to be translated
into a real bandwidth value.  The same problem existed with ATM
(see tons of research on finding a good "equivalent capacity" for
a connection).  At that point, the overbooking ratio may be used as
one of the ways for ensuring efficient utilization of resources.

-Anoop