The MPLS WG Archive

[Curtis Villamizar <curtis@avici.com>]

In message <39ABFC4A.EC9CF12B@marconi.com>, David Charlap writes:
> 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


This is not PCR and SCR.  Different problem.  Square peg, round hole,
... etc, etc.

TCP backs off very nicely when congestion occurs so long duration
transfer get a little slow for a while (minutes, hours) and then go
faster as load lessens.  A fair amount of traffic is still
asynchronous bulk transfer (last I looked) and the majority (HTTP) is
interactive bulk transfer and is not perceptibly impacted by mild
congestion and only gets annoying when moderate congestion occurs.

Curtis