Subject: Re: ADSPEC format

From: "Karl Auerbach" <[email-masked]>
Date: Tue, 3 Sep 1996 16:17:20 -0700

Your suggestions make a lot of sense to me.

I do find the position dependent padding between parameter headers and
parameter values to be troublesome.  I expect it may be a source of bugs
that won't quickly surface during the typical interoperability testing
between genetically similar implementations.

The length fields in the message and service header are non-intuitive to me
since, at least in the service header, there's those two bytes that follow,
but which are in the uncounted word and which may contain either padding or
a parameter header.

Making *all* headers and parameters a multiple of 32-bits makes a whole lot
of sense to me.

I'd also like to suggest that there be clear statements regarding the
ordering (or lack of ordering) of the parameters within a service.  (I've
already implemented code that doesn't care about the ordering of parameters
within a service, so it is easy for me to say "let's be flexible about
ordering.")

Additional items which I find to be troublesome:

 - The truncated guaranteed parameter fragment in the adspec.  It seems
that this role
could be performed by using the non truncated form if we were to use the
per-parameter valid/invalid flags.

 - The lack of specified ordering (or lack of ordering) on the parameters
in the "service-specific general parameter headers/values, if present"
field of guaranteed and controlled-load fragments.

In addition, I'm not really sure that it's a win to have the adspec with an
overall generic parameter service, then have the guaranteed and controlled
load services contain overrides.  It would be cleaner to my mind if we
dispensed with the generic part, and simply move those parameters into each
of the specific services.   Thus each service fragment would stand alone. 
It might cost a few more words in the packet, but these packets aren't
going to be large and the extra space isn't going to be noticeable.

                    --karl--

---

From: [email-masked]
Date: Wed, 4 Sep 96 08:16:02 PDT

I don't think it's actually broken, maybe just a little crinkley about
the edges...

Bob

---

From: Fred Baker <[email-masked]>
Date: Wed, 4 Sep 1996 10:07:05 -0800

At 8:21 AM 9/4/96, [email-masked] spluttered:
> Sorry, but I don't quite get why we need a length field for the
> parameters.  The parameter type always uniquely defines a length,
> doesn't it?  There are no actual variable-length parameters.

why do we have a length field on an IP option? I always heard that the
reason was so that someone could define a new one, and routers that didn't
know what to do with it would know how to correctly ignore it.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I don't suffer from insanity.  I enjoy every minute of it.

---

From: [email-masked]
Date: Wed, 4 Sep 96 10:16:11 PDT

*> From [email-masked] Wed Sep  4 10:08:20 1996
  *> X-Sender: [email-masked]
  *> Mime-Version: 1.0
  *> Content-Type  *> :   *> text/plain  *> ;   *> charset="us-ascii"  *> 
  *> Date: Wed, 4 Sep 1996 10:07:05 -0800
  *> To: [email-masked]
  *> From: Fred Baker <[email-masked]>
  *> Subject: Re: ADSPEC format
  *> Cc: [email-masked], [email-masked]
  *> Content-Length: 591
  *> X-Lines: 13
  *> 
  *> At 8:21 AM 9/4/96, [email-masked] spluttered:
  *> > Sorry, but I don't quite get why we need a length field for the
  *> > parameters.  The parameter type always uniquely defines a length,
  *> > doesn't it?  There are no actual variable-length parameters.
  *> 
  *> why do we have a length field on an IP option? I always heard that the
  *> reason was so that someone could define a new one, and routers that didn't
  *> know what to do with it would know how to correctly ignore it.
  *> 

Fred,

Beware; I don't think you want to go down that track.  Your comment
raises the idea that an intserv data structure fragment (as defined by
JTW) must be treated as a completely variable set of parameters, which
must be parsed every time you touch it.  That is a piece of generality
that I think is potentially much harder to implement than the current
situation, where you can map these thingys at compile time.

Fragments have lengths so unknown service types can be skipped.  Within
a fragment, there is a known set of parameters in a known order at
known offsets, except perhaps for some unknown parameters at the end.

Bob

---

From: Roch Guerin <[email-masked]>
Date: Thu, 05 Sep 1996 08:02:28 -0400

I fully agree with Karl's point which was one of the reason I sent out
the first note, and while I certainly want the specs to stabilize I
again agree with Karl that these latest and detailed formats have not
be out for very long.  In addition, I also think that one of the
purposes of initial interoperability testing is to flush out things
and bring up a number of implementation issues that different people
have been running into.  I would think that the specs have to remain
flexible enough to accommodate these as it will in the end make for a
better and more robust standard.
Roch
------- Forwarded Message

Date:    Wed, 04 Sep 1996 16:25:04 -0700
From:    "Karl Auerbach" <[email-masked]>
To:      <[email-masked]>, <[email-masked]>
cc:      <[email-masked]>, <[email-masked]>
Subject: Re: ADSPEC format

>   *> >   *> > I couldn't make a C struct fit over this.
>   *> > 
>   *> > Please see rapi_lib.h in ISI implementation; it worked for me
(which
>   *> > is why I don't see a need to rush out and change it).
>   *> 
>   *> I'm not making the assumption of a fixed ordering or parameter set
within a
>   *> service.

If one is reading a guaranteed service fragment the placement of padding
within individual parameters of the generic overides will vary depending
which of those parameters are present.  There's no way to slap a C
structure over the minimum path latency parameter in the override section
because it will contain padding if the path bandwidth estimate is present
but not if it is preceeded by the IS hop count parameter.

In other words, if one is going to do the aspec generic override fields in
the controlled load or guaranteed services, then a C structure isn't going
to work -- the existance and placement of padding depends on which
parameters are actually present.
 
> That's admirable, I guess.  I think it's time to stop changing the
> spec, however.

No it isn't... we're essentially at day 1 of interoperbility testing of the
int-serve
formats.  For those of us not in the "inner circle", these new formats have
been out for less than a month.  And those changes were not small,
incremental changes.  Rather they were radical.  Somehow that doesn't give
me the comfortable feeling that stability has arrived.

		--karl--

------- End of Forwarded Message

---

From: [email-masked]
Date: Fri, 6 Sep 96 09:24:48 PDT

*> 
  *> A simple way to parse service data fragments is as follows:
  *> 
  *>  a) blat a C structure over the service header and service-specific=20
  *>     parameters, and process them.
  *>  b) check the length field of the service fragment to see if it is larger
  *>     than the "standard" length. If it is not, you are done.
  *>  c) If it is, parse the override general parameters one by one, until you
  *>     come to one you don't recognize, or until you run out of words in the
  *>     fragment. In either case, you are done.

...

  *> 
  *> The only way to fix this is to align/pad all parameter header/data pairs=
  *>  exactly the same way, so they can be blindly moved. This could be either=
  *>  completely unaligned (fully packed), or everything aligned to a word=
  *>  boundary, or whatever. It doesn't matter, as long as everything is the=
  *>  same. Fred has suggested packing, others have suggested word-alignment.=20
  *> 

John,

If I understand this, it seems that it does matter whether you pack or
align.  If you pack, then you can't "blat" a C structure over the known
parts at the beginning.  [So I am agreeing with your ultimate conclusion].

Bob

---

From: Fred Baker <[email-masked]>
Date: Fri, 6 Sep 1996 10:43:15 -0800

At 9:02 PM 9/5/96, John Wroclawski spluttered:
>The only way to fix this is to align/pad all parameter header/data pairs
>exactly the same way, so they can be blindly moved. This could be either
>completely unaligned (fully packed), or everything aligned to a word
>boundary, or whatever. It doesn't matter, as long as everything is the
>same. Fred has suggested packing, others have suggested word-alignment.
>
>With this change the parsing rules above still work, and still don't need
>a length field.

I'm not sure I see how putting it always on a word boundary removes the
need for a length field. Do we know that all objects forever will require
exactly 8 bytes?

I think you're better off having the length field, if you're going to
change this, and while I don't have an argument against it, I don't see the
point of padding.

It would help me to see you put this in specific bits and bytes.
Specifically, I want to know how this changes the adspec, the sender tspec,
and the flow spec.