Subject: Re: new version of data encodings I-D

From: [email-masked]
Date: Wed, 13 Dec 1995 08:05:41 -0800

*> J. Wroclawski                 Expires 6/96                      [Page 5]
  *> INTERNET-DRAFT  draft-ietf-intserv-data-encoding-01.txt   December, 1995
  *> 
  *> 
  *> 
  *>    Message Header Field
  *> 
  *>        31    28 27                   16 15                            0
  *>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>        | V     |    Unused             |     OVERALL LENGTH            |
  *>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *> 
  *> 
  *>    V               - Flowspec version; currently 0
  *>    OVERALL LENGTH  - Overall length in 32-bit words not including header
  *> 

John,

Here are some comments on this document.  They result from my actually
trying to USE to write code.

This message header field appears to be redundant, creating unnecessary
complexity and coding.  The version can/should be handled by the C-Type
field of the enclosing object framing, and the length is redundant with
the object length.  When I implement this, I must check that the object
C-Type = 1 and that your version = 0 and that your overall length field
matches the enclosing object length.  It looks ugly and is redundant.

  *> 
  *>    Service-Specific Data Header Field
  *> 
  *>        15             8 7             0
  *>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>        |  SVC_NUMBER   |  LENGTH       |
  *>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *> 
  *>    SVC_NUMBER      - Service ID number (defined in service specification)
  *>    LENGTH          - Service-specific data length in 32-bit words,
  *>                      not including header.
  *> 
  *> 
  *>    Parameter-ID Header
  *> 
  *>        15             8 7             0
  *>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>        |  PARAM_NUM    |   PARAM_FLAGS |
  *>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>                         I
  *>                         n
  *>                         v
  *> 
  *>    PARAM_NUM       - Parameter ID number (defined in service specification)
  *>    PARAM_FLAGS     - Flags. Currently:
  *>                      INV (Invalid) (bit 7) - This parameter may be invalid.
  *> 
  *> 

As I pointed out in a separate message, the alignment rules do not
seem to allow Unix struct declarations to define structural building
blocks in the usual way.  In your example below, you cannot declare
a struct for a parameter that can be used for either (e) or (g),
because of differing alignment.  The result will be very, very awkward to
code, I think.  The natural building block is a Parameter; but that
will only work if the Parameter-ID Header is expanded to 32 bits and
thus forced into fullword alignment.

Why do you exclude the header word from the length?  This differs from
customary protocol practice (for which there is a good reason), and
it seems unnecessarily confusing.

Bob

---

From: John Wroclawski <[email-masked]>
Date: Wed, 13 Dec 1995 19:06:53 -0500

From: [email-masked]

   the object length.

Bob,

C-Types et al sound very RSVP-specific. Are you assuming that the
data encoding of this note will be used only with RSVP?  That's not
the intention of the document. It is defining a data encoding for use
by anyone that wants to use it, and it wasn't obvious to me that all
such people would have an 'enclosing object framing' defined.

Then there are situations such as the one shown in the picture below

      o    Class = 9, C-Type = 254:  Unmerged Flowspec List

           +-------------+-------------+-------------+-------------+
           //                 FLOWSPEC object  1                  //
           +-------------+-------------+-------------+-------------+
           //                 FLOWSPEC object  2                  //
           +-------------+-------------+-------------+-------------+
           //                                                     //
           +-------------+-------------+-------------+-------------+
           //                 FLOWSPEC object  k                  //
           +-------------+-------------+-------------+-------------+

where you are packing several intserv data objects into the same
message. The message header gives you a way to do that without any
additional framing mechanism from the higher-level protocol.

I agree, though, that there are situations where the message header is
partially redundant. I considered a two-level approach which would
allow you to avoid using it if your application already had an overall
framing defined. I rejected this because it would eliminate the place
for the encoding version field, as well as adding (more) complexity to
the spec and making it more difficult to write library software which
allows RSVP or whatever to treat these messages as opaque objects.

So that a mistakenly zeroed length field would not put the parser into
an infinite loop. If I recall correctly this was suggested by Steve
Casner, based on experience from RTP. 

		-john