Subject: question on traffic policing

From: [email-masked]
Date: Mon, 10 Apr 1995 15:43:19 -0700

Hi.  All the current draft service specs say about Traffic
Specification and Policing:

   "Policing is done at the edge of the network and at all source merge
   points."

Would you expect that any service that does policing will do it this
way?  More specifically, RSVP currently defines a single flag to the
kernel "policing is needed", and turns it on for either the edge of
the network or a source merge point.  Is one flag enough, or should
the two conditions be distinguished in the interface?

Thanks,

Bob Braden

---

From: [email-masked] (Fred Baker)
Date: Tue, 11 Apr 1995 10:21:34 -0700

At 10:45 AM 4/11/95, John Krawczyk wrote:
>Packets that exceed their
>Tspec are dealt with as defined in the service definition."  All of
>the current service definitions say to drop these packets.

which is my first case, and what I do. I agree that the word needs to be
defined; if I were a host vendor, I would be absolutely certain that it
meant that the router cleaned up my mess :^)

My comment on predictive service in this context: note that the RSVP draft says

   6.5 Flowspec Class

      o    CSZ FLOWSPEC object: Class = 5, C-Type = 1

            +-----------+-----------+-----------+-----------+
            |                QoS Service Code               |
            +-----------+-----------+-----------+-----------+
            |        b: Token Bucket Depth (bits)           |
            +-----------+-----------+-----------+-----------+
            |        r: Average data rate (bits/sec)        |
            +-----------+-----------+-----------+-----------+
            |        d: Max end-to-end delay (ms)           |
            +-----------+-----------+-----------+-----------+
            |              (For Future Use)                 |
            +-----------+-----------+-----------+-----------+

           QoS Service Code

                Integer value defining what service is being requested.
                The values currently defined for this code are:

                1 = Guaranteed Service

                     The Tspec is (b, r), while the Rspec is (r).  (d)
                     is ignored.

                2 = Bounded-Delay Predictive Service

                     The Tspec is (b, r), while the Rspec is (d).

If the reservation is installed according to the Rspec, I would expect the
Rspec to indicate the bandwidth that I am reserving AND the maximum queue
depth. The Tspec is optional, and therefore may not be available. I'm not
maintaining long term averages in the fast path of the router, I'm testing
for presence of maximum queue depth. That's my policing. I need the
bandwidth for admission control. If I have a 512 KBPS line and two
reservations of unknown bandwidth (I only know that the guy wants me to
sign up for fast service), I'm going to ACK one and NAK the other. If I
have a 512 KBPS line and two reservations of 64 and 384 KBPS respectively,
I can probably ACK both.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
computers run on smoke, it if leaks out they won't run

---

From: [email-masked]
Date: Tue, 11 Apr 1995 13:32:28 -0700

*> 
  *> My comment on predictive service in this context: note that the RSVP draft says
  *> 
  *>    6.5 Flowspec Class
  *> 
  *>       o    CSZ FLOWSPEC object: Class = 5, C-Type = 1
  *> 
  *> 

Fred,

I wouldn't take too seriously what is in the RSVP draft.  I dreamed it
up largely as a place-holder to indicate the general style.  We could
update it now from the draft service templates, but they are now
acknowledged to be somewhat ill-formed (maybe only Guaranteed
service?).  Or, we could wait for int-serv to do it... :-)

Bob