The 75xx has one queue per physical interface. As such, it would
seem quite improper to assume that separate streams of traffic are
queued separately.
In order to get nice traffic shaping, this should be pushed out to
the application device. Note that this is generally handled quite
nicely by TCP, available on most hosts :-)
The ATM_Lite had only one queue as far as I can recall, w/ the ATM
Deluxe having multiple queues.
I don't think you are whining over nothing, but focus on the
fact that the limiting of packet transmission rate will cause
TCP to conform to that bandwidth without peaking too near the
upper constraint.
I must confess I'm unclear as to how buffering and CAR work
together, except to know that there's a single queue. It would
seem that anytime the 'drop' CAR functionality is employed,
it is just dropped. Since there's no 'buffer' option, I'd suggest
that the 'transmit' then throws it towards the queue. Sounds like
I need to go play in the lab.
-a
Thus spake Alex Bligh (amb@gxn.net)
on or about Sun, Jul 05, 1998 at 07:28:14PM +0100:
> 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