Subject: Re: Flowspec format

From: [email-masked] (Fred Baker)
Date: Mon, 10 Apr 1995 16:47:29 -0700

At 3:48 PM 4/10/95, [email-masked] wrote:
>During the RSVP WG meeting, it was suggested that the formats of flowspecs
>(exclusive of the RSVP-specific object header wrapper) should properly
>be defined in the corresponding service templates.

Seems to me this is a syntax vs semantics discussion. I'm comfortable with
the syntax being in the RSVP spec and the semantics being in the
IS-Services Specs. Right now, the semantics are partly in the IS-Services
Specs, partly in the RSVP Spec (the fact that the predictive flow
specification is only concerned with the maximum time in queue, for example
- which I disagree with, if you want me to sign up for more than one of
them, you better tell me the average flow rate, so I have some clue as to
what promises I'm making) and is partly unspecified (though I could
probably work those things out if pressed).

If we're going to get into specifying the syntax in the IS-Services specs,
I can think of some quarters that would prefer 64 bit integers. This
viewpoint is reflected in the WINSOCK-II API. I'm not arguing for that (far
from it), just pointing it out...

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

---

From: [email-masked]
Date: Mon, 10 Apr 1995 17:14:20 -0700

Fred,

OK, my argument is that (at least) the range and scale of the data
in a flowspec ought to be defined in the service document, not in
the RSVP protocol document.  Having done that, int-serv might as
well lay out the bytes and specify the representation (e.g., fixed
vs. floating point).

Bob

---

From: [email-masked] (Fred Baker)
Date: Mon, 10 Apr 1995 17:27:07 -0700

>well lay out the bytes and specify the representation (e.g., fixed

I'm not going to argue the syntax. I *do* think the semantics ought to be
extremely explicitly blatant and obvious to the most extremely anal idiot
who picks up the int-serv spec. If its not, we'll be coming back to fix it,
I guarantee it. Been there...

---

From: [email-masked]
Date: Tue, 11 Apr 1995 09:10:56 -0700

*> 
  *> 
  *>     During the RSVP WG meeting, it was suggested that the formats of flowspecs
  *>     (exclusive of the RSVP-specific object header wrapper) should properly
  *>     be defined in the corresponding service templates.
  *> 
  *>     Do you agree with this?  If not, should we discuss it?  If so, will you
  *>     update the template documents, so I can point the RSVP spec at them?
  *> 
  *> Bob:
  *> 
  *> I'm not sure I agree.  I need to think about this.
  *> 
  *> Remember that most of the operations on the various data types (TSpecs,
  *> Rspecs and return values) are done by RSVP.  From that perspective, one
  *> might assume RSVP should specify its preferred format.
  *> 
  *> Craig
  *> 

Craig,

I think JTW would say that it is NOT RSVP that does operations on the
data types; it is a thin "adaptation" layer which we have not named,
lying perhaps "between" RSVP and the kernel.

Bob

---

From: [email-masked]
Date: Tue, 11 Apr 1995 09:17:13 -0700

*> 
  *> Seems to me this is a syntax vs semantics discussion. I'm comfortable with
  *> the syntax being in the RSVP spec and the semantics being in the
  *> IS-Services Specs.

Fred,

Put another way:  as long as integers are represented by finite bit fields,
one can't totally separate syntax from semantics.

Bob

---

From: [email-masked]
Date: Tue, 11 Apr 1995 15:50:10 -0700

*> 
  *> If we're going to get into specifying the syntax in the IS-Services specs,
  *> I can think of some quarters that would prefer 64 bit integers. This
  *> viewpoint is reflected in the WINSOCK-II API. I'm not arguing for that (far
  *> from it), just pointing it out...
  *> 

I think 64-bit values is a lousy idea.  The compact floating point
representation that Craig Partridge suggested in his flowspec RFC seems
much better.  Large potential range and small precision are appropriate.

But maybe that's too radical...

Bob

---

From: [email-masked] (Fred Baker)
Date: Tue, 11 Apr 1995 16:44:59 -0700

At 3:50 PM 4/11/95, [email-masked] wrote:
>Large potential range and small precision are appropriate.
>

I'm comfortable with it, if we can put it into an implementation in the
near future.