Subject: Re: Fw: MPLS and CAC

From: Kireeti Kompella <[email-masked]>
Date: Tue, 29 Aug 2000 10:43:24 -0700 (PDT)

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.

Kireeti.

---

From: David Charlap <[email-masked]>
Date: Tue, 29 Aug 2000 14:09:14 -0400

Kireeti Kompella wrote:
> 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).
> 

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 29 Aug 2000 22:36:15 -0400

> overbooking parameters to get the same effect.

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

---

From: David Charlap <[email-masked]>
Date: Wed, 30 Aug 2000 11:27:45 -0400

> congestion and only gets annoying when moderate congestion occurs.

And what does this have to do with how a transit router makes
reservations?

Once data enters a tunnel, it is supposed to be opaque to the routers
until it exits that tunnel.  The fact that it may be using a layer-4
protocol with congestino control does not mean a switch can ignore its
reservations.

-- David

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 30 Aug 2000 12:26:24 -0400

> And what does this have to do with how a transit router makes

The reservation amounts are based on historic measurements (ie: over
the course of days or longer) of LSP utilization.  This is the way
many ISPs set the bandwidth parameter as reported in the TE WG.  These
bandwidth amounts can be significantly different from the actual
offerred load.  My first point (not quoted above) was that the
bandwidth on reservations is often wrong.  My second point (above) is
that things work even though the reservation amounts are wrong.
That's the only thing it has to do with making reservations.

> protocol with congestino control does not mean a switch can ignore its

If a resource (a link or a queue implementing a shore on that link) is
overbooked, some data is lost.  That's where active queue management
(RED) comes into play.  This is an expected behaviour for BE and for
services such as AF.  My point was that the behavior observed by the
end user for mild congestion is imperceptibly different from
uncongested operation.  This is why it makes sense to an ISP as a
service offering and is in fact a very attractive service offering.

The Internet works and is a viable and growing business in case nobody
on this thread has noticed.  My comments above were just intended as
insights into why it works despite not offering guarentees.

Curtis