Subject: ADSPEC format

From: Roch Guerin <[email-masked]>
Date: Tue, 03 Sep 1996 16:35:48 -0400

John, 

We had a couple of questions concerning the current format for
the ADSPEC objects as they have been designed.  In particular, in your
document draft-ietf-intserv-rsvp-use-00.txt you present examples of
how they are to be arranged and their format, and we would like to
suggest some slightly different formats for the purpose of simplifying
implementation.

Specifically, only service headers (including general
characterization) have a length field, and the fact that the length of
individual parameters can vary can complicate both the parsing of
messages as well as create a number of other problems.

For example, if we later want to introduce a new general
characterization parameter, we will need to upgrade all existing
implementations to be able to recognize this new parameter even if
they don't really need to, e.g., it's for some service optimization
purpose.   This is because they would not know how to skip it since
they don't have a clue of how long it is.
You could possibly decide that any new parameter would be
put at the end of the service data fragment, but this may still cause
problems to some implementations and is also not something you really
want to impose.

Another example of the problems created by the current formats is when
you want to over-ride a general characterization parameter in a
service specific data fragment.  The fact that general
characterization parameters have different lengths and zero-padding
that is actually dependent on the order in which they have been
inserted, makes for a rather messy situation.

Therefore, what we would like to suggest is to instead have all
parameters be on word boundaries, i.e., the padding is
within the parameter itself, and also include a length field (can take
some of the flag bits for that).  This will simplify parsing and
service specific over-rides of general characterization parameters as
well as facilitate future extensions.  It's obviously less efficient
in terms of the associated overhead, but the gain in implementation
simplicity and flexibility for extensions seem worth it.

What do you and others think about this?

Thanks,

Ping and Roch

---

From: John Wroclawski <[email-masked]>
Date: Thu, 5 Sep 1996 21:02:41 -0400

Roch, all,

When I wrote the RSVP-USE note I tried, among other things, to stick within the message format originally written up in the data-encodings draft of last november, even at some cost. But I agree that we really do need at least one change, though for slightly different reasons than have been brought up so far.

Sorry this note is so long. The first half describes how the current spec is supposed to work, and the second half points out a couple of specific problems and fixes.

At 4:35 PM -0400 9/3/96, Roch Guerin wrote:
>John, 
>
>... we would like to suggest some slightly different formats for the 
>purpose of simplifying implementation.
>

Actually, the requirement you mention ("any new parameter would be put at the end of the service data fragment") *is* imposed by the current spec, and is crucial.

This constraint is contained in the ordering rule for parameters in a service data fragment, which says that a fragment contains:

  a) the service-specific parameters, followed by
  b) any override general parameters present, ordered numerically by
     parameter-name.

These rules make it possible for new services and new general characterization parameters to be introduced without breaking existing code. I certainly agree that being able to do that is vital.

I assume that a) a service's service-specific parameters are fixed, because we are following a no-optional-parameters rule in service specifications, and b) new parameter names are assigned sequentially as new general characterization parameters are defined.

A simple way to parse service data fragments is as follows:

 a) blat a C structure over the service header and service-specific 
    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.

>inserted, makes for a rather messy situation.

Seems to me that *parsing* these things is fairly straightforward (but see problem 2 below). Continuing with the above example, code for parsing override parameters might look something like this. It assumes a table containing the size of each parameter you know about, and an ALIGN macro which does the usual <add size-1 and zero the LSB's> operation. 

char *pp = <end of service-specific parameters>;
parameter_header *ph;

while (<there is data left in service fragment>) {
	pp = ALIGN(pp, sizeof(parameter_header);
	ph = (parameter_header) pp;
	pp += sizeof(parameter_header);
	if ( <we've never heard of PARAMETER_NUMBER(*ph)> )
		break;
	pp = ALIGN(pp, parameter_size_table[ PARAMETER_NUMBER(*ph) ];
	parameter = * (<type_of_parameter *>) pp;
	pp += parameter_size_table[ PARAMETER_NUMBER(*ph) ]
}

(Our code actually did this by putting pointers to little helper functions in the paremeter array, and dispatching through it, but the structure is the same. The helper functions took care of data conversion, processing the parameter value, and building the new message to be sent to the next node.)

Now then. I know of two problems with the above. One of them can be dealt with simply enough that I decided to ignore it for the sake of stability. Unfortunately the other one, which I just realized while writing this note, really needs to be fixed.

--- Problem 1 (the minor one) - the precise wording in the spec works with ADSPECS but not with possible future SENDER_TSPECS.

Right now, all SENDER-TSPEC objects contain only a Token-Bucket-Tspec parameter, number 127.  

(I gave it 127 because it is a globally defined, rather than per-service defined parameter (and so has a number < 128), but it is not a "characterization" parameter. So I started numbering from the top down to distinguish this. This was perhaps a mistake.)

In the future, we might find that SENDER-TSPECS need to be more complicated. For example, a sender might want to specify different token bucket tspec values for  G service than for CL. This could be done by putting the token-bucket-tspec inside a Guaranteed (number 2) service fragment, rather than in a general service fragment (number 0). This would work OK.

But another thing which might be desirable, if we ever invent a service which does -not- use a token bucket tspec, is to include more than one type of tspec in the service 0 fragment. If such a thing is defined, it would currently be number 126, and, following the ordering rules above, it would be first in the fragment. This would screw up existing implementations which did not understand the new kind of tspec.

Some ways I considered fixing this were to change the t-b-tspec number from 127 to a low number, to state that sender-tspecs order parameters down rather than up, to add a length field as you suggest, or to go to a new (version 1) format if it ever became necessary.

--- Problem 2 (the real one) - it is impossible for an intermediate node to *add* an override parameter to a service fragment (that is, override something that wasn't overridden before) if the service fragment contains one or more override parameters that the node doesn't know about. The reason is that adding a parameter in the middle of the (ordered) override params list may change the alignment/padding of parameters following it in the list, but if you don't know about those parameters you can't rewrite them correctly.

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. 

But there is one more thing to consider, which is whether a *per-parameter* break bit is useful. If a new general characterization parameter is introduced,
it would be helpful to know whether some routers on the path didn't understand it. To do this we need them to set a bit in the header of each parameter they didn't recognize. To do *that*, we need a length field in each parameter, so a router can find the headers of the second and successive parameters it doesn't understand and set the bit. (Note that this is different than the current INVALID bit, which says that the router knows perfectly well what this parameter means but doesn't want to deal with it).

So:

I think we have to fix problem 2. I'd do this by changing the alignment rules to everything-on-a word-boundary, based on the majority of the people who've mentioned the issue to date preferring to keep aligned-access and on my own experience writing Alpha code. The cost is a few bytes (currently anywhere between 0 and 10 or so) per service fragment.

I propose to keep the ordering rules of the current spec, so that the fast fragment parsing technique I described above continues to work (in fact with the change above it gets a little faster).

Since we're here, I would define the unknown-parameter flag in the header as above, which implies also adding the length field. At present, neither of these things are absolutely necessary, but they are very simple and good insurance for the future. 

These are essentially the changes Roch proposed, + the addition of the unknown-parameter bit. (Karl Auerbach also proposed the same alignment change in a private message).

Comments?

-john

---

From: Roch Guerin <[email-masked]>
Date: Fri, 06 Sep 1996 13:57:24 -0400

John, thanks a lot for your very detailed and thorough note.  It was
very helpful.  Now, concerning the solutions you propose, I totally
agree with them (that was easy ;-)
Roch

>So:
>
>I think we have to fix problem 2. I'd do this by changing the alignment> rules to everything-on-a word-boundary, based on the majority of the people> who've mentioned the issue to date preferring to keep aligned-access and on> my own experience writing Alpha code. The cost is a few bytes (currently> anywhere between 0 and 10 or so) per service fragment.
>
>I propose to keep the ordering rules of the current spec, so that the fast> fragment parsing technique I described above continues to work (in fact> with the change above it gets a little faster).
>
>Since we're here, I would define the unknown-parameter flag in the header as> above, which implies also adding the length field. At present, neither of> these things are absolutely necessary, but they are very simple and good> insurance for the future. 
>
>These are essentially the changes Roch proposed, + the addition of the> unknown-parameter bit. (Karl Auerbach also proposed the same alignment> change in a private message).
>
>Comments?