The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

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.

-- David