Subject: Re: Fw: MPLS and CAC

From: "Erickson Trejo-Reyes" <[email-masked]>
Date: Mon, 28 Aug 2000 22:05:50 +0100

Mr Chen,

No, I certainly don't know if there is any document that speaks of the subject. I would certainly try to find something in the literature, and yes, I agree with you that having others' impressions of this would be rather constructive. Thanks for your answer and we'll keep in touch.

Best regards,

Erickson Trejo

-----Original Message-----
From: C. Chen <[email-masked]>
To: Erickson Trejo-Reyes <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Monday, August 28, 2000 9:51 PM
Subject: Re: Fw: MPLS and CAC

Mr.  Erickson, 
It seems to me that overbooking factor determination is not simply PCR * activity factor (e.g., .4). I was wondering wether there is a IETF draft defining overbooking factor that you know of ? If not, I would like to suggest that we work together with people who might be interested in participating to make a draft contribution on this suject. 

Best Regards, 

Cheng C. Chen 

Erickson Trejo-Reyes wrote: 

 Thank you both David and Curtis for your kind answers. Refering the following statement in the possible configuration: > While CAC is fully supported it can essentially be ignored by setting a very high overbooking factor... > With the high overbooking, these tunnels come up anyway.  If there are preferred services, they get preferred treatment so the overbooking doesn't matter to them.  Best effort services temporarily get squeezed... therefore oversubscribing is much more preferrable to having CAC kick in and losing 100% of the traffic until things settle down. 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)? 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? Again, thanks in advanced,  Erickson

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 29 Aug 2000 17:03:29 -0700

> From: David Charlap [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2000 11:09 AM
> To: [email-masked]
> 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

---

From: Ram Krishnan <[email-masked]>
Date: Wed, 30 Aug 2000 17:02:00 -0400

Even with Gold customers, you can do this as long as you
can characterise the traffic profiles of your Gold customers
carefully and provision parameters such as effective bandwidth
and buffer space accurately.

Regards,
Ram

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

Kireeti.