> There shouldn't be any problems pushing a DS3 well beyond 99% utilization,
> by the way. With an average packet size of 500 bytes and 98 packets in the
> output queue on average, 99% only introduces a 9 ms delay. The extra RTT
> will also slow TCP down, but not in such a brutal way as significant
> numbers of lost packets will. Just use a queue size of 500 or so, and
> enable (W)RED to throttle back TCP when there are large bursts.
One problem you have here is how you are getting the utilization statistics.
Since you are looking at 5 minute averages, chances are real good that
your instantaneous figure is probably at the full capacity of the DS-3.
Of course. 99% utilization means the circuit is busy 297 seconds of every
300 second period (not that Cisco's figures are computed like that).
As you approach the maximum capacity and start dropping packets,
your throughput on the line will bounce around near the 45 megs figure but
the "goodput" that the customer sees will drop dramatically. You will
be sending retransmissions of the dropped packet, which then causes
less bandwidth to be available for current traffic,
Yes, this is exactly what happens with the default 40 packet output queue.
But if you increase the queue, excess packets won't be dropped, but
buffered and transmitted after a slight delay. No problems with
retransmissions and backoffs, and the circuit is used very efficiently.
The only problem is that bulk transfers don't care about the increasing
RTT and keep sending, while interactive traffic suffers as the queue size
grows. So you need RED as well to keep the bulk transfers in check.
My experience in the real world is that once
you get over 40 mbps on a DS-3 you need to look at upgrading.
Agree, but that's not always (immediately) possible.
Another thing I would question
is where the Cisco is counting traffic. Since it is most likely looking at
the real user traffic there is more likely some overhead to manage the
DS-3 itself and some L2 protocol stuff also.
My experience with heavily congested <= 2 Mbps circuits is that the kbps
figure the router shows gets _very_ close to the actual number of bits
per second available to layer 2. So they must be doing this the right way,
including PPP overhead and even bit stuffing, which is obviously something
you wouldn't want to count in software.
This is definitely a factor when running ATM because the router only
counts the input/output traffic after the ATM overhead has been
Looks that way. But only the ATM cell headers or also the AAL5 and RFC
1577 (or what have you) overhead?
Iljitsch van Beijnum