RE: [nsp] ATM VBR on Cisco

From: Travis Pugh (tpugh@shore.net)
Date: Wed Feb 14 2001 - 08:03:49 EST


On Wed, 14 Feb 2001, Martin, Christian wrote:

Hi Chris ... answers in-line:

> Travis,
>
> Comments in line...
>
> What are your SCR and PCR values? What is the propagation delay on the
> link?

90000 pcr 80000 scr 250 burst. Prop delay is somewhere in the 30s,
although I'm taking the GX switch at it's word for that.

> We've seen some things before, but they are often a problem with the carrier
> switch. Lucents CBX line often is the culprit. In this case, however,
> there should be no buffering due to shaping delay because of a full bucket
> (your delay is high enough to drain the bucket for a one-hundred byte
> packet.)

I think we've eliminated the switch. As I understand it, since this is a
UNI interface, it is not necessary to have the router and the switch agree
as to the class of service. We turned off the vbr-nrt router config on a
pvc that is vbr on the ATM switch, and latency went away. The atm switch is
still configured vbr on the pvcs, but the router isn't, and the ping times
are 36/36/40, just like ubr.

I turned on "ubr 80000" and it had no additional latency, either. vbr
seems, by default, to add a large amount of variance to the latency across
the link when I configure it on the cisco, and at least on a Dallas to LA
run it adds 10ms to the average.

>
> Buffering happens on both devices, but for different reasons. On the
> router, the tx_ring empties based on scheduler information fed from the SAR
> driver. If the tx_ring fills, then packets sit in the SRAM buffers until a
> free tx_ring slot opens. This is shaping.
>
> On a switch (assuming no shaping is being performed), buffering happens per
> service class with different scheduling priorities per class. The buffering
> is high on VBRnrt links to accomodate bursts and cell-clumping resulting
> from upstream congestion. This is controlled by the Burst Tolerance and the
> Cell Delay Variation Tolerance values, respectively.
>
> In order to understand this fully, it is best that you get a copy of
> "Quality of Service in ATM Networks" by Giroux and Ganti. See
>
> http://www.amazon.com/exec/obidos/ASIN/0130953873/o/qid=982127123/sr=8-1/ref
> =aps_sr_b_1_1/105-9507683-4846311

I'd rather get a POS backbone, but given the circumstances I'll certainly
look the book up. Thanks.

>
> I really don't see a major issue here, although the delay jitter is slightly
> anomalous. You may wish to open a case with the TAC and have them look into
> a possible software defect in the driver code. Of course, Siva may have an
> answer before you even get the case queued!

We're pursuing with TAC. I don't see a whole lot of a throughput problem
with this situation, but it is adding roughly 20ms latency to a
cross-country route, which is annoying both from a "speed" perspective and
from the ability to hand the almighty customer decent cross-country SLA
statistics.

>
> regards,
> chris

thanks.

-travis



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:29 EDT