I wonder if someone can answer this question definitively. Every
time I talk to Cisco they give me the answer I want to hear,
but ever time I look at the documentation, it implies something else.
Let's say I have an ethernet segment attached to a router on which
I'm running dCEF & dCAR. I have a number of other (let's say non-Cisco)
devices such as web servers on this segment.
I wish the router to simulate the situation where each device is
(say) bridged onto the LAN using a standard clocked serial connection
(let's forget bursting for the moment). So I could, for instance,
have server 1 connected "as if" it were connected via a T1, and
server 2 connected "as if" it were connected via a DS0.
Well dCAR does rate limiting, so there shouldn't be a problem, I hear
you say. Well not quite.
Let's assume the traffic to/from the server is bursty. When the
traffic is above the committed access rate, in the "real serial"
version, the output buffer will start to fill. I can set the buffer
quite large if I want. And well before packets start to drop, the
RTT will increase. On a good day, the TCP/IP stacks at either end
will interact with this increase in RTT and slow down or at least
not speed up. That way they will fill the line without dropping piles
of packets on the floor.
However as far as I can tell there are only two actions that can be
taken with "non-conforming" traffic under CAR. It can be dropped
or propagated (plus or minus some change in IP precedence). Queuing
appears not to be an option. Now it is I suppose possible that
the documentation has missed the fact (or I've missed the documentation)
saying that the packets themselves are queued (and hence delayed)
in some dual-leaky-bucket-type way, with individual rate queues, but
the documentation would seem to imply that the rate queues are merely
token buckets, i.e. the packets themselves won't be delayed on their
way. This appears to be confirmed by the statement:
> CAR propagates bursts. It does no smoothing or shaping of traffic.
But then I go and read all the good stuff written about the ATM
equivalents, and how intelligent queuing, shaping and discard
policies are vital to getting decent TCP/IP performance
(Foresight etc.).
So am I mistaken about CAR, or is the implementation no more
than dumb policing? And if so, how do I get decent traffic shaping
for a web farm? (I already know the various ATM-based solutions but
they seem like overkill to me). Does anyone do this with CAR
not-withstanding? If so, does it make a difference? Am I whinging
about nothing?
-- Alex Bligh GX Networks (formerly Xara Networks)
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:13 EDT