Subject: Re: New draft of controlled-load service spec

From: [email-masked]
Date: Wed, 13 Dec 1995 07:53:16 -0800

*> 
  *> 5. Invocation Information
  *> 
  *> 
  *>    The controlled-load  service is invoked by specifying the data flow's
  *>    desired traffic parameters (TSpec) to the network element. Requests
  *>    placed for a new flow will be accepted if the network element has the
  *>    capacity to forward the flow's packets as described above. Requests
  *>    to change the TSpec for an existing flow should be treated as a new
  *>    invocation, in the sense that admission control must be reapplied to
  *>    the flow. Requests that reduce the TSpec for an existing flow (in the
  *>    sense that the new TSpec is strictly smaller than the old TSpec
  *>    according to the ordering rules given below) should never be denied
  *>    service.
  *> 
  *>    The TSpec takes the form of a token bucket specification plus a
  *>    minimum policed unit (m) and a maximum packet size (M).
  *> 

John,

Just before IETF, Fred took the int-serv folks to task for deliberate
vagueness.  I'm on Fred's side, and I don't think much progress has
been made.  Why don't you come right out and say it: the Tspec takes
the form of a token bucket FOLLOWED BY m FOLLOWED by M?  Nowhere that I
can find do you actually state the ORDER of the parameters; I don't
accept the (very useful) examples at the end as a definition.

  *>    The token bucket specification includes a bucket rate r and a bucket
  *>    depth, b.  Both r and b must be positive.  The rate, r, is measured
  *>    in bytes of IP datagrams per second. Values of this parameter may
  *>    range from 1 byte per second to 40 terabytes per second. Network
  *>    elements MUST return an error for requests containing values outside
  *>    this range. Network elements MUST return an error for any request
  *>    containing a value within this range which cannot be supported by the
  *>    element. In practice, only the first few digits of the r parameter
  *>    are significant, so the use of floating point representations,
  *>    accurate to at least 0.1% is encouraged.
  *> 

Encouraged?

  *>    The bucket depth, b, is measured in bytes. Values of this parameter
  *>    may range from 1 byte to 250 gigabytes. Network elements MUST return
  *> 
  *> 
  *> 
  *> J. Wroclawski                 Expires 6/96                      [Page 5]
  *> INTERNET-DRAFT  draft-ietf-intserv-ctrl-load-svc-01.txt   December, 1995
  *> 
  *> 
  *>    an error for requests containing values outside this range. Network
  *>    elements MUST return an error for any request containing a value
  *>    within this range which cannot be supported by the element. In
  *>    practice, only the first few digits of the b parameter are
  *>    significant, so the use of floating point representations, accurate
  *>    to at least 0.1% is encouraged.
  *> 

Encouraged?

  *>   The preferred concrete representation for the TSpec is two floating
  *>   point numbers in single-precision IEEE floating point format followed

Preferred?

Well, when you write a TCP implementation, I ENCOURAGE you to send 32
bit unsigned integer sequence numbers, and I would PREFER that you use
16 bit unsigned integer port numbers.  But I guess you COULD use double
precision floating point sequence numbers if you really wanted to...

C'mon guys, this is an Internet protocol specification, not an
academic paper.  Let's get real (or integer, as the case may be).

Bob

---

From: John Wroclawski <[email-masked]>
Date: Wed, 13 Dec 1995 20:17:54 -0500

From: [email-masked]

   [...] Why don't you come right out and say it: the Tspec takes
   the form of a token bucket FOLLOWED BY m FOLLOWED by M?  Nowhere that I
   can find do you actually state the ORDER of the parameters; I don't
   accept the (very useful) examples at the end as a definition.

Bob, 

A little later in your note you quoted from the following chunk of
document...

 The preferred concrete representation for the TSpec is two floating
 point numbers in single-precision IEEE floating point format followed
 by two 32-bit integers in network byte order.  The first value is the
 rate (r), the second value is the bucket size (b), the third is the
 minimum policed unit (m), and the fourth is the maximum packet size
 (M).

   Preferred?

Preferred. If you want to design a setup protocol that represents
these parameters as ASCII strings for easy debugging, who am I to stop
you?

   C'mon guys, this is an Internet protocol specification

Well, no, it's not. It's a service specification, which is meant to be
accessable to any control protocol that wants to use it. So, it both
tells you in words what information you have to carry, and it
specifies a standard 'preferred' format for carrying it. If your setup
protocol wants to use the preferred format, you can incorporate it by
reference. If you can't use that format for some reason, you have
enough information to pick another one that you can use.

		-john

---

From: [email-masked] (John Krawczyk)
Date: Thu, 14 Dec 95 09:26:30 EST

On Wed, 13 December, John Wroclawski ([email-masked]) wrote:

      From: [email-masked]

   Well, no, it's not. It's a service specification, which is meant to be
   accessable to any control protocol that wants to use it.

(Stepping in here carefully.. :).

People,

Can we get some consensus here so we can avoid more of these types of
arguments?  To carry Bob's TCP analogy further, John think's he's
writing a document on what a reliable, connection-oriented, end-to-end
protocol looks like.  Bob thinks John's writing RFC 793.

I had thought that the service documents _were_ supposed to be
generic, except for the appendices, in which "protocol specification"
preciseness is needed.  I've previously suggested to a few people that
separate documents be written to describe "Service XXX over RSVP", but
I like the idea of having everything in one place.  However, if we
can't all agree on what the content of the service documents should
be, I'd like to see the protocol specifics pulled out (actually, if we
can't agree on this basic point, we're in big trouble).

-jj