Subject: Re: latest draft of guaranteed

From: [email-masked] (Fred Baker)
Date: Mon, 15 Jul 1996 11:14:14 -0700

At 10:19 AM 7/15/96, Craig Partridge wrote:
>It isn't quite that simple.  One has to worry about cases in which some
>receivers want guaranteed and some want controlled load (in which case
>there are nifty problems of replacement).

of course, but that's one thing we all agree that we haven't figured out.
There would have to be some conversion rule and some replacement hierarchy.

I'm trying to get what we *have* figured out into production.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
When people run around and around in circles we say they are crazy.
When planets do it we say they are orbiting.

---

From: John Krawczyk <[email-masked]>
Date: Mon, 15 Jul 96 15:02:22 EDT

Here are a couple of suggestions from a humble implementor....

1) TSPEC.

The CL spec has two Tspecs; a CL specific version and a generic version.
The G spec has a single Tspec that looks a lot like the CL generic Tspec
(the only real difference is the service number; bugs and typos make up
the rest of the diffs).

For this pass, since we have one Tspec that seems to work with both
services, why don't we settle on that one and get rid of the rest?  Here
it is (jtw's text with the lengths fixed):

         31           24 23           16 15            8 7             0
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | 0 (a) |    Unused             |             6 (b)             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     1 (c)     |    5 (d)      |    1 (e)      |     0 (f)     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Minimum Policed Unit [m] (32-bit integer)                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Maximum Packet Size [M]  (32-bit integer)                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      (a) - Version number (0)
      (b) - Overall length (6 words not including header)
      (c) - Service header, service number 1 (generic information)
      (d) - Length of per-service data, 5 words not including header
      (e) - Parameter ID, parameter 1 (TSpec)
      (f) - Parameter 1 flags (none set)

2) ADSPEC.

The G spec contains an ADSPEC with 4 parameters specific to the G
service and two pieces of generic info (min latency and composed MTU).
Why not call this a "generic" ADSPEC?  We could require that a PATH
_always_ contains this, and we deal with multiple service support in one
of the following two ways:

   Define a bit in the unused flags field to mean "this parameter is
   invalid".  In other words, if a PATH hits a router that only does CL, it
   sets the "invalid" bit in the appropriate flags fields.

   -or even better-

   If a PATH hits a router that doesn't support a parameter, it simply
   removes it from the ADSPEC (a receiver could get an empty ADSPEC...).

Using either of these methods, it should be pretty clear to a receiver
which service(s) it can request.

Does this work?  Comments?

-jj