Subject: Re: Policing issues

From: [email-masked] (Fred Baker)
Date: Fri, 12 May 1995 09:24:13 -0700

At 11:27 AM 5/12/95, Dilip Kandlur wrote:
> This is a per-service decision. For example, a service intended for
> use with rate-adaptive applications will likely use the marking
> approach you describe. For controlled-delay, dropping is likely to be
> the best choice.
>
>Does the controlled delay service attempt to control jitter in any
>form?  If not, I don't see why dropping packets is the best choice.

Not really - what it says is that the router/switch will introduce as
little jitter as it can get away with consistent with the promises it has
made to other traffic in queue. If I have ten streams using a given level,
it is possible for all senders to simultaneously send, and for the
introduced jitter for one to be as large as nine of their messages. If the
router has some streams at a more-delay level but has already held some
messages in that queue for their allotted time, they become relevant in the
calculation as well.

It seems to me that traffic shaping in the sense of holding traffic in a
queue and transmitting it based on a timer (shaping in the truest sense) is
never really the job of the router/switch, except perhaps when attached to
a data link network where the access rate doesn't predict the virtual
circuit's throughput rate. A minimal-impact traffic shaping in the sense of
holding things that can afford to wait in queue longer than traffic that
requires quicker service is implicit in the whole concept here. "Policing"
is therefore what you do when you reach the ropes, when minimal-impact
traffic shaping (fancy queuing) isn't working. It seems like the only
option left at that point (the point where you can't effectively manage
traffic by queuing) is dropping. Dropping is *never* the best choice, given
a non-dropping option. But the other options were exhausted in traffic
shaping.