Subject: [manet] Comments about draft-ietf-manet-packetbb-08

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 09 Aug 2007 16:05:03 -0700

Hello folks,

Here are some comments about the newer revision.

In section 5.3.2, there is the following constraint:

>    Two or more TLVs with the same tlv-fulltype in the same address block
>    TLV block MUST NOT be associated with the same copy of an address
>    (i.e. they must not have overlapping index ranges).

I don't think this is right.  Suppose I have a TLV type
that associates sets of values to a set of addresses
(for instance, sequence numbers or values for stability).
To my understanding, I could not include this TLV
type twice in a message, because the address ranges
would overlap.

I don't see any advantage in imposing this constraint,
and it seems to me that it should be removed.

Also, these constraints:

>    TLVs in the same TLV block MUST be sorted in non-descending tlv-
>    fulltype order.
and

>    TLVs with the same tlv-fulltype associated with the same address
>    block MUST be sorted in ascending index-start order.

while probably harmless otherwise, seem to
serve little purpose other than requiring
protocol parsers to perform additional sorting
operations and creating new error conditions
that might need to be checked on the receiving
ends.  What is the specification for offending
packets?  Would the packet be silently dropped,
or would each protocol be free to handle the
unsorted TLVs in protocol-specific fashion?

As I had mentioned previously (before the last
IETF meeting), it would be a good idea if we
could have 8-bit <tlv-length> fields, in order to
minimize the TLV overhead.  This can be done
without adding new fields to the <tlv-block>
definition (e.g., no <tlv-block-semantic> vector),
and thus (I reckon) not significantly impacting
the parseability of the result.  For instance, we
could just say that 16-bit <tlv-blocks> cannot
exceed 32,767 bytes in length, and use the
leading bit of the <tlvs-length> element of the
<tlv-block> to signify that <tlv-lengths> has only
7 bits.

More later...

Regards,
Charlie P.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 10 Aug 2007 07:49:13 +0530

Comments inline.

> and it seems to me that it should be removed.

The same tlv type can be twice included, but not for the same address.

I believe this requirement is to disallow there being multiple TLVs of
the exact same type associated with one address. For example, if you
have address Z and it has two tlvs of the same type with different
values, then what is the value associated with this tlv? By explicitly
disallowing multiple values with the same tlv type, we can ensure this
does not occur.

Ian Chakeres

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 10 Aug 2007 10:11:03 -0700

Hello Ian,

> The same tlv type can be twice included, but not for the same address.

That is what packetbb says, but I am certain that nodes in an ad hoc
network can have more than one "characteristic", and we need to have
a way to put those multiple characteristics into messages.
> disallowing multiple values with the same tlv type, we can ensure this
It is a nonfatal protocol error to include two incompatible values or
characteristics for the same node.  Usually in cases like this there is a
specification that mandates acceptance of the last incompatible value,
or the first one -- as long as all protocol entities do the same thing.

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 13 Aug 2007 11:38:33 +0100

With regard to the constraints in packetbb:

- Specifying ordering and non-duplicate TLVs in packetbb
  looks like it adds complexity, but it really reduces
  implementation complexity, as the following points
  indicate.

- It may add complexity to the packet/message generation,
  but very little. Adding no duplication adds no work, it's
  what you should do. Adding ordering just makes you insert
  new TLVs in the right place rather than at the end, you
  don't actually sort. You may even generate them in the
  appropriate order in the first place, in which case there
  is no added complexity.

- Now at the receiver you can tell a malformed TLV block
  (and hence message, and if you choose, packet) at the
  parsing stage, and very easily.

- With a duplicate TLV you don't need to force complex
  decisions as to whether you use the first, or most
  restrictive, or whatever, choice. It is malformed by
  definition and you can allow the implementation to
  do what it considers sensible - and that can be the
  easy decision to discard the packet/message/block.
  And note that this can be at parsing, not processing.

- Thus receiver processing can be (and probably should
  be) much simpler.

- This is aside from the additional gain in reduced
  searching for TLVs (stop when not found).

- Philosophically, once you get a malformed message,
  do you trust the sender? Do you want to try to make
  the best of it? Do you just want to ignore it? The
  decision is that of the receiver implementor.

For these reasons I am strongly against removing any
of these contraints.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Mon, 13 Aug 2007 09:50:22 -0400

>It may add complexity to the packet/message generation,

I disagree with this assessment. While it may place no 
additional complexity on the implementation *now*, 
it may in the future, depending on what TLV's are 
added, and what their numbering scheme is. 

This is something that networking systems have 
handled for longer than I care to remember. Even
(dare I say it?) SNA didn't have this restriction.

In sum, I agree with Charlie -- this restriction adds 
complexity where its not needed, and I think it should
be lifted. 

Regards,
Stan

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 13 Aug 2007 15:02:31 +0100

I don't agree. I have general purpose packetbb code that
is quite agnostic as to whether it's being used for OLSRv2
(for example) or not, and has no built in knowledge of
current or (obviously) future TLVs, and this has minimal
impact on generating packetbb messages (when you add a
TLV it either slots in, or reports an inconsistency in
what you requested, and doesn't add it) and this makes
the parsing/reception at the other end much easier. So
I'm not just hypothesising, I have (to use a phrase)
running code, which does consider the future as well.

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 13 August 2007 14:50
To: Dearlove, Christopher (UK); [email-masked]
Cc: Thomas Clausen
Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Regards,
Stan

---

From: Bo Berry <[email-masked]>
Date: Mon, 13 Aug 2007 10:33:21 -0400

I'll have to agree with Stan and Charlie.  Parsing
TLV and sub TLVs should not require an ordering.
While your code may be agnostic, I think the
comments are on the draft, not your code (we've not
seen the code...).

in-line

-Bo

>   And note that this can be at parsing, not processing.

I think it would be beneficial if the draft provided
guidelines on parsing errors vs processing errors.
Doing so would facilitate interoperability.  There
are two sides to the problem, how the originator
handles the error and how the receive handles the
error. A degree of synergy can only help.

<tlv-semantics>  is an 8 bit field specifying the interpretation of
      the remainder of the TLV:
   ...cut...
      bit 1 (extended) and bit 2 (novalue):  MUST NOT both be set ('1').
   .....

For example, what if both bits are set?  What MUST the code
NOT do?  Or WHAT MUST the code do?  There are other places
that would benefit from some level of guidance.

> - Thus receiver processing can be (and probably should

This may be case today in your opinion, but may not be the
reality if the protocol evolves.  It appears this is a
concern that deserves more discussion.

>   searching for TLVs (stop when not found).

Perhaps this is a parser rule that should be added to the
draft.  .... stop and discard the message.... ?

---

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Mon, 13 Aug 2007 10:33:54 -0400

But the problem with your running code is the "reports an
inconsistency in what you requested, and doesn't add it" 
part. That is what may require, as we add TLV's in the
future, that a chain of TLV's be re-ordered before it is 
sent. 

Regards,
Stan

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 13 August 2007 14:50
To: Dearlove, Christopher (UK); [email-masked]
Cc: Thomas Clausen
Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08

               *** WARNING ***

Regards,
Stan

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 13 Aug 2007 15:42:35 +0100

If I get that message there's a fault in the code using
the packetbb code. Having that in the packetbb code is
a "belt and braces" thing.

There is never a reason to reorder TLVs. Each TLV has a
type. When you add it, insert it in the right place. When
you add the next TLV, insert that in the right place.
Reorderinf never required.

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 13 August 2007 15:34
To: Dearlove, Christopher (UK); [email-masked]
Cc: Thomas Clausen
Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08

Regards,
Stan

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 13 August 2007 14:50
To: Dearlove, Christopher (UK); [email-masked]
Cc: Thomas Clausen
Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08

               *** WARNING ***

Regards,
Stan

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 13 Aug 2007 16:10:55 +0100

Yes, you've not seen the code. But my point is that I
have what I believe is a solid argument why ordering
adds trivially to the complexity at the transmitter,
and reduces complexity at the receiver. The point of
mentioning the code is that my argument is backed by
experience doing it, it's not just academic. In addition
this was introduced based on a suggestion from one of the
contributors other than the authors, who are more driven
than I am by complexity considerations. I'm hoping he, or
a colleague, will join in this discussion.

Your inline comments on erroneous packets. We do address
this issue in NHDP/OLSRv2. I think (and note that here I
haven't yet discussed this point with the other authors)
it is not the place of packetbb to say what a protocol
using packetbb must do. It may be the place of packetbb
to explicitly say that handling an erroneous packet is
up to the protocol. This could include listing the most
obvious actions to take (discarding the packet or discarding
the message) and possibly noting that in some cases no other
options than these are possible. This we could probably add.
But packetbb is not itself a protocol, it's not, I think, for
it to require a specific single behaviour, in particular not
to specify which of the choice of the two discard options is
appropriate. (There are also, in some cases, other possible
options, such as just discarding a TLV block, although I do
not think these appropriate to NHDP/OLSRv2.)

(There is also an issue as to when parsing occurs - OLSRv2
has explicit permission for "just in time" parsing, only
doing so when necessary, not automatically on reception, but
while also permitting that - this allows implementations to
trade off different forms of complexity.)

In this context an erroneous packet (or message) would
be (I think, I need to check) defined as anything which
doesn't match the regexp specification, or which violates
a MUST.

-----Original Message-----
From: Bo Berry [mailto:[email-masked]] 
Sent: 13 August 2007 15:33
To: Dearlove, Christopher (UK)
Cc: Stan Ratliff (sratliff); [email-masked]; Thomas Clausen
Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08

in-line

-Bo

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 13 Aug 2007 09:58:12 -0700

Hello Chris,

>   implementation complexity, as the following points
I just do not believe this, having written one
or two such parsers...
>   what you should do.
My message to you was intended to indicate that one
SHOULD be allowed to provide duplicate tlv-typed
extensions for certain foreseeable cases.
>  Adding ordering just makes you insert
You cannot know this for all future uses of packetbb.  You can know
it for OLSRv2 perhaps, although I would even doubt that given some
of its foreseeable extensions.
>   parsing stage, and very easily.
My point is that such packets should not be considered malformed.
>   And note that this can be at parsing, not processing.
With a duplicate TLV you can do whatever the specification
indicates, including making use of the valid contents to record
more data about nodes and topology.
> - Thus receiver processing can be (and probably should
Or not, if prohibiting duplicates requires torquing the
protocol design unnecessarily.
>   searching for TLVs (stop when not found).
Sorry, but this is completely unresponsive to the point.
>   decision is that of the receiver implementor.
Please refer to my suggestion that these packets
should not be considered malformed.
> For these reasons I am strongly against removing any
I don't think these reasons are responsive to my points, and given
recent discussion I think it is more clear that the constraints
should be removed.

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 13 Aug 2007 18:07:56 +0100

>I don't think these reasons are responsive to my points

I believe they are responsive in that they argue why
the constraints should be retained.

I find your position inconsistent. On the one hand you
argue for saving every last octet (with which I don't
agree, flexibility is important) but here you are
arguing for a hypothetical future need (more than one
TLV of the same type associated with the same address
- note that more than one TLV of the same type in the
same TLV block is valid) with no use case and which is
against the TLV philosophy in packetbb, despite that
it adds complexity, not reduces it, where it matters.

I strongly disagree that you have made a good case for
removal, let alone that the case is clear, and I strongly
oppose removing the constraints.

---

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Mon, 13 Aug 2007 13:27:34 -0400

>Sent: Monday, August 13, 2007 1:08 PM
>To: Charles E. Perkins; [email-masked]
>Cc: Thomas Heide Clausen (work)

Odd. I don't find the position to be inconsistent; it is simply 
a case of favoring additional computational complexity over
transmission size. I agree with the position, because 
1. In low-power devices, the transmitter is often the device
that consumes the most energy, and 
2. As packet size goes up, so does probability of error. 

>oppose removing the constraints.

The main case, as Charlie stated, is that you cannot know,
for all future uses of packetbb, what processing order the 
TLV's will need to be inserted in, hence, packets that 
contain either out-of-order or duplicate TLV's should not 
be considered malformed. This approach seems to provide 
the maximum flexibility, and as you state, "flexibility is important".

Regards,
Stan

---

From: "Justin Dean" <[email-masked]>
Date: Mon, 13 Aug 2007 14:34:09 -0400

My thoughts on the constraint issues.  For clarity the text of the document.

1  TLVs in the same TLV block MUST be sorted in non-descending tlv-
   fulltype order.

2  Packet and message TLVs MUST be defined so as to indicate whether two
   TLVs with the same tlv-fulltype are, or are not, allowed in the same
   packet or message TLV block, respectively.

3  Two or more TLVs with the same tlv-fulltype in the same address block
   TLV block MUST NOT be associated with the same copy of an address
   (i.e. they must not have overlapping index ranges).

4  TLVs with the same tlv-fulltype associated with the same address
   block MUST be sorted in ascending index-start order.

1 and 4 deal with ordering of the tlvs within a packet.  I can see how its
advantageous to have this ordering but I can also see how it may not be
necessary.  

The major advantage I can see is with 1 is being able to read a lack of a
tlv by the ordering without having to read the entire tlv block.  If
multiple protocols in an integrated system are only looking for specific tlv
types they can more quickly decide if the information is there or not, i.e.
if I am looking for page 10 and I get to page 11 then its not there no need
to read the next 100 pages.  It is not NEEDED, however, protocols based off
of packetbb MUST know if this constraint is true for all packetbb packets or
this advantage is lost.

The advantages of 4 are a little bit less clear but the same principle
applies.  And if the ordering is not stated here for both 1 and 4 no later
document can later state ordering constraints and have it work for all
packetbb protocols.

I think 2 is something everyone can agree on as it allows both types of
behaviors for a message/packet tlv.

With 3 this was introduced to avoid confusion on which value should be used.
I personally would be ok with wording this closer to 2 in mandating that the
tlv definitions explicitly disallow or allow.  There are issues with
allowing this but there may also be an advantages.  A hypothetical example;
10 addresses each of which is either bright or dark and blue or red
1 bright red
2 bright blue
3 bright red
4 bright red
5 bright red
6 dark red
7 dark blue
8 dark red
9 dark red
10 dark red

Under the current constraints it would require 1 indexed tlv for bright 1
indexed tlv for dark, then either a m-tlv for all the addressed or a mixture
of m-tlvs and indexed tlvs for the color.  If constraint of more than one
was lifted for the color tlv a m-tlv for all nodes being red and then 2
single tlvs for the 2 blue nodes may reduce overhead.

My current feelings on these
1. I am in favor if keeping it.
2. Keep.
3. More on the fence and leaning towards revised wording closer to 2.
4. Less in favor of keeping than 1 but still leaning towards keeping it.

Justin

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 1:28 PM
To: Dearlove, Christopher (UK); Charles E. Perkins; [email-masked]
Cc: Thomas Heide Clausen (work)
Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08

Regards,
Stan

---

From: Bo Berry <[email-masked]>
Date: Mon, 13 Aug 2007 14:59:14 -0400

in-line

> a colleague, will join in this discussion.

But several of us have and are speaking up from
our experience and perspectives in designing & developing
TLV based protocols, routing, metrics.

I think what's required is an open mind to consider the
feedback and experience of others. Perhaps the WG Chairs
can help moderate.

> options than these are possible. This we could probably add.

That comment should be added.  I also think there is room
to add guidance for specific cases that are designed in
packetbb.

> not think these appropriate to NHDP/OLSRv2.)

OK, packetbb is not itself a protocol.  It is the basis from
which manet protocols are to be designed and developed.  That
being the case there are specific error cases as result of
the design.  It seems logical that rules/guidance be included.

> doesn't match the regexp specification, or which violates

Yes, implementations may format and parse messages differently.
All the more reasons why some rules/guidance would be helpful.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 13 Aug 2007 12:48:32 -0700

Hello Chris,

I am trying to understand your point of view, but ...

> the constraints should be retained.
The body of your message characterized such TLVs
as "malformed", and then concluded that malformed
packets should not be allowed by the protocol.

That is not responsive.
> argue for saving every last octet
Not by any means.  I guess you haven't seen me in
my "minimal implementation" mode...
>  (with which I don't
> agree, flexibility is important)
So far, none of my suggestions would have
decreased flexibility.  Even my suggestions from
before the IETF would not have done this.
>  but here you are
> same TLV block is valid) with no use case
Do you mean that I didn't submit a protocol specification?
That's placing the bar pretty high...  I did explain the need,
but I can do it again if need be.
>  and which is
> against the TLV philosophy in packetbb,
I somehow did not find any point within the specification
which elucidated packetbb's TLV "philosophy".  Could
you be more explicit?  Or else maybe it is in some e-mail
I didn't read yet...  I will look.
>  despite that
But I claim and believe that my suggestions reduce
complexity.  The argument from complexity in the case
of allowing overlapping address ranges is a trade-off,
but the other suggestions seem to me to clearly
enable less complicated protocol operations.

For overlapping address ranges, I guess one would
have to define multiple TLV types (with the attendant
additional packet overhead and specification complexity)
in order to "allow" multiple descriptors for some but
not all addresses in a range.  Or maybe whole new
messages -- a real botch since it would require either
very complicated bundling arrangements or else whole
new packets and medium access operations.
> oppose removing the constraints.
Well, you have certainly made that clear enough.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 13 Aug 2007 12:59:50 -0700

Hello Justin,

I have some follow-on comments on the points you raise.

> of packetbb MUST know if this constraint is true for all packetbb packets or
Actually, I think that any protocol using packetbb should make any such
necessary constraints in the individual protocol document.  Since other
protocols may not have the same requirement, it is not needed to impose
the constraints globally for all time.  Perhaps, if it is needed to 
expedite the
information lookup as you are suggesting, packetbb could recommend that
individual protocol specifications include a relevant section near the front
of the document (just after the protocol applicability statement?).
> document can later state ordering constraints and have it work for all
But any individual protocol can do so, and that is, I think, all that is 
needed.
> tlv definitions explicitly disallow or allow.
I am also O.K. with wording closer to (2).

Regards,
Charlie P.

PS. I should have included the four cases, I guess... so here they are.

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 14 Aug 2007 05:37:44 +0200

Charlie, Bo, Stan, Justin, all.

I'm an insomniac today (it's 5AM here), so I'll toss in a few thoughts.

In general, I agree 100% with Justin's analysis of the situation and  
his presentation of why the constraints are as they are accurately  
reflect the reasoning behind the document. The same with the email of  
Chris where he presents his thoughts on how the constraints serve to  
reduce complexity. I shall not repeat Justins' and Chris' excellent  
emails here, but rather add a few thoughts:

	- Since packetbb is intended to carry, in one packet, a set of  
messages, and since
	  these messages may be for different protocol instances (and, even,  
different
	  protocols), then some level of coordination is required in  
packetbb for this. At least,
	  packet-tlv's would have to either have or not have the  
constraints, and these
	  constraints would have to be specified somewhere, that an  
implementation can
	  correctly deal with incoming packets. packetbb seems the logical  
place.

	- Having a set of constraints for packet-tlv's and then different  
constraints for message
	  TLVs and address-block TLVs (and, possibly, different constraints  
for TLV blocks in
	  different message types) is messy: it'd break the ability to have  
one piece of code
	  constructing (or parsing) all TLV blocks identically and sanity- 
checking of all things
	  packetbb. That is: it'd dramatically increase the code footprint  
required to make a
	  packetbb parser/generator, and any such would no longer be generic.

	  I should add that going from RFC3626 (which doesn't use packetbb)  
to OLSRv2
	  (which uses packetbb) not only resulted in a dramatic net  
reduction of the control
	  message size but also roughly cut the size of the packet/message  
parsing/generating
	  code by 2/3. Since the packetbb structure is intended exactly for  
making general
   	  components, I can (and, indeed, have) reuse the same code for  
other protocols or for
	  protocol extensions.

	  So I second also Chris' comment that having these constraints  
reduces the complexity,
	  but in a different way than what he indicates: it allows me to  
write code that consistency
	  checks packets/messages once, rather than having to do so for each  
protocol/extension
	  I think up. Obviously, I agree with Chris' issues on how it  
reduces complexity in the receiving
	  end without adding to the complexity of the sending end

	- One of the requirements (and now I am repeating Justin's argument)  
for packetbb
	  that has been brought forward at least as early as the Paris IETF  
(when these
	  constraints were introduced and formalized) was to be able to  
terminate processing
	  of a TLV block early -- i.e. as Justin say, if you're looking for  
page 10 and you get to
	  page 11, then you can stop without reading the next 100 pages if  
you know that
	  the pages appear in order.

	  We had intense discussions on this in Paris and Vancouver, and I  
was convinced that
	  there was/is rough consensus behind this. I shall not be speaking  
on behalf of the
	  participants in these discussions (which, btw., were open to  
anyone caring to join them),
	  but very clear requirements from real deployments and real  
customers and manufacturers
	  were presented for this, and were throughly discussed at that  
point already.

While the discussion as to if we can or cannot or should or should  
not do something based on some hypothetical future is interesting, I  
am more concerned with the fact that we are operating within a design- 
space where we've got companies providing real stuff to real  
customers having real requirements, presenting these requirements and  
participating in the specification that has now become packetbb. I  
think that our goal is to satisfy that concrete and real design-space.

In conclusion, I'm strongly in favor of retaining the constraints as  
they are, since I've seen a strong case for them and I have seen no  
solid case for removing them.

Thomas

On Aug 13, 2007, at 9:59 PM, Charles E. Perkins wrote:

> But any individual protocol can do so, and that is, I think, all  
> that is needed.

-- 
Thomas Clausen
[email-masked]
http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
http://www.lix.polytechnique.fr/hipercom/

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 14 Aug 2007 05:49:18 +0200

Bo,

Comments below.

On Aug 13, 2007, at 8:59 PM, Bo Berry wrote:

> feedback and experience of others.

All due respect, but I think that if anything then packetbb and  
related protocols have been developed with "an open mind" -- at  
least, the specification has evolved substantially from what was  
originally presented in Paris ('05) due to the feedback received  
since then and until the WGLC was issued.  Also, I think that keeping  
an open mind when reading and evaluating the packetbb specification  
would be helpful: the requirements and constraints are there for a  
reason, as I think the emails from Chris and Justin both have explained.

> Perhaps the WG Chairs

I think that Joe/Ian have done so well in the past, and are doing so  
well at the present. See the quote below:

> This note starts the WG Last Call for comments on
> draft-ietf-manet-packetbb-07.txt, "Generalized MANET Packet/Message  
> Format".
>
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-07.txt
>
> The document is intended to be submitted for publication as an
> proposed standard document.
>
> Please review the document carefully and send your comments to the
> MANET list and document authors.
>
> This last call will end Friday July 20th.
> Thanks,
> Ian Chakeres

Thomas

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 14 Aug 2007 09:37:40 +0100

Thomas has said most of what I would say, but I would
just like to stress

> feedback and experience of others.

And that is exactly what these constraints are. I didn't
invent them, nor did Thomas. They came precisely out of
other people's experience.

---

From: "Justin Dean" <[email-masked]>
Date: Tue, 14 Aug 2007 10:35:38 -0400

The reason I say protocols can not make ordering requirements on their own
is for an envisioned system where two protocols are using the same packetbb
"code engine".  This would save duplicate packets and become more efficent
than both protocols opperating seperatly.  If the first of these protocols
requires ordering but the 2nd does not the first may make the wrong
assumption that the tlv/address is not present when it is just out of order
because the 2nd added some out of order tlv/address.  Actually nhdp/olsr
nhdp/smf are an example of this and they would break if nhdp requires
ordering but olsr does not.

Justin

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 4:00 PM
To: ext Justin Dean
Cc: [email-masked]
Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08

Hello Justin,

ext Justin Dean wrote:
> The major advantage I can see is with 1 is being able to read a lack 
> of a tlv by the ordering without having to read the entire tlv block.  
> If multiple protocols in an integrated system are only looking for 
> specific tlv types they can more quickly decide if the information is
there or not, i.e.
> if I am looking for page 10 and I get to page 11 then its not there no 
> need to read the next 100 pages.  It is not NEEDED, however, protocols 
> based off of packetbb MUST know if this constraint is true for all 
> packetbb packets or this advantage is lost.
>   
Actually, I think that any protocol using packetbb should make any such
necessary constraints in the individual protocol document.  Since other
protocols may not have the same requirement, it is not needed to impose the
constraints globally for all time.  Perhaps, if it is needed to expedite the
information lookup as you are suggesting, packetbb could recommend that
individual protocol specifications include a relevant section near the front
of the document (just after the protocol applicability statement?).
> applies.  And if the ordering is not stated here for both 1 and 4 no 
> later document can later state ordering constraints and have it work 
> for all packetbb protocols.
>   
> I personally would be ok with wording this closer to 2 in mandating 
> that the tlv definitions explicitly disallow or allow.

Regards,
Charlie P.

---

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Tue, 14 Aug 2007 13:49:10 -0400

Thomas,

>to OLSRv2 (which uses packetbb) not only resulted in a dramatic net  
>reduction of the control message size but also roughly cut the size of
the 
>packet/message parsing/generating code by 2/3. Since the packetbb 
>structure is intended exactly for  making general components, I can 
>(and, indeed, have) reuse the same code for other protocols or for
>protocol extensions.

Do you have any data that you'd be willing to share that compares the 
path length and latency to generate a control plane message using 
OLSRv2+packetbb versus RFC3626? 

Regards,
Stan

>From: Thomas Clausen [mailto:[email-masked]] 
>Sent: Monday, August 13, 2007 11:38 PM
>To: Charles E. Perkins; Stan Ratliff (sratliff); Bo Berry (bberry)
>Cc: ext Justin Dean; manet manet; Christopher Dearlove

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 14 Aug 2007 21:11:11 +0200

> OLSRv2+packetbb versus RFC3626?

I've got some data -- path lengths obtained are the same (anything  
else would surprise me) between OLSRv2 and RFC3626.

If by "latency to generate a control plane message" you mean the time  
it takes for a router to construct a mesage....then that's something  
I've never measured in either of the two. It should, however, be  
obvious that this is one of the places where one can do various  
things (make various compromises) and get various results. I do not  
know if anyone has actually looked at this in any great detail in any  
of the MANET protocols.

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 14 Aug 2007 12:54:06 -0700

Hello Thomas,

I deleted the other respondents to your previous email.

To some extent, we could compare the TLV ordering
constraint to imposing an ordering on command-line
options.  Of course it is do-able, but a good way to
make people angry.  We do not know all the future
protocol designers, and so it is easy to validate making
them angry since one can claim ignorance of their needs.
Maybe, after all, they are just weird by packetbb
standards.

To respond to your points:

ext Thomas Clausen wrote:
> reflect the reasoning behind the document.

 Solidarity is good in many cases...
 
>       these messages may be for different protocol instances (and, 
> even, different
> packetbb for this.

 I think this feature will be more valuable for some systems than for
others, and I don't see that it is relevant to the discussion about the
constraints, but ...
 
>       At least,

 That is debatable, and I do not think it is logical to place such 
constraints
for all future designs.
 
>       TLVs and address-block TLVs (and, possibly, different 
> constraints for TLV blocks in
>       different message types) is messy: it'd break the ability to 
> have one piece of code
>       constructing (or parsing) all TLV blocks identically and 
> sanity-checking of all things

 Maybe you are right, and that all the different types
of protocol element blocks should not have any ordering
constraints.   But it seems to me that you are broadening
the discussion unnecessarily.  I don't fully understand your
point about different constraints.  If I had to write a single
subroutine for parsing the TLVs, it would have a type-dependent
boolean flag specifying the existence of an ordering constraint.

That is not "dramatic".  And, it serves also to validate my
belief that the objections are really based on exaggerated
claims about difficulty.

>
>
>       I should add that going from RFC3626 (which doesn't use 
> packetbb) to OLSRv2
>       code by 2/3. Since the packetbb structure is intended exactly 
> for making general

 You didn't explicitly mention the second-system effect,
which any good programmer knows is (in fact!) dramatic.
 
>       checks packets/messages once, rather than having to do so for 
> each protocol/extension

 Solidarity is good, but in this case I really think you are
claiming more difficulty than exists.  You either check the
ordering or you don't!  O.K., there are a few more braces
in the source code...
 
>
>     - One of the requirements (and now I am repeating Justin's 
> argument) for packetbb
>       that has been brought forward at least as early as the Paris 
> IETF (when these
>       of a TLV block early -- i.e. as Justin say, if you're looking 
> for page 10 and you get to

 Here I would compare to command-line processing.

And, by the way, the pages in many books are unnumbered.
Sometimes it matters, sometimes not.
 
>       there was/is rough consensus behind this. I shall not be 
> speaking on behalf of the

 I guess you mean the discussions did not occur
in the working group meetings or on the mailing
list.  Anyway it sailed clear past me without leaving
any discernable memory or impression.
 
>
> While the discussion as to if we can or cannot or should or should not 
> do something based on some hypothetical future is interesting, I am 
> more concerned with the fact that we are operating within a 
> design-space where we've got companies providing real stuff to real 

 Did you want to talk about how companies cite experimental RFCs
in their in their RFPs and even in standards documents?  I'm a big
fan of real customers.  I am having a hard time believing any company
would tell you "We _need_ monotonically increasing TLV types".
I can believe they would tell you "We need slim parsers".  Of course
we all do.  But my suggestions are NOT increasing the size of the
parser.  In fact, if you completely eliminate the ordering, the parser
would be smaller.

Moreover, you would really need to allocate the TLV types with
a lot of spaces in between the numbering, to avoid having types
with fractional or irrational values.  But maybe anyway we should
have more transcendental types :-)  [ommmmm]

For designs that want to have early termination, _that_ really does
belong in the protocol specification, and presumably would be
trivial to check.

These are very general remarks, supplied just in response to your
points.   I'll try to be more specific in response to other more
specific emails.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 14 Aug 2007 13:48:54 -0700

Hello Justin,

Your argument can be drawn to extremes that would,
for instance, require all TLVs to have exactly the same
structure.  But I know you did not mean that.

As a practical matter, though, it seems to me that what
you are really asking for is to have available a toolkit
for protocol processing that is at the same time sufficient
for getting the work done but not too large to fit in the
cabinet.

I am suggesting that relaxing the ordering mandate
does not substantially increase the footprint of the toolkit.
I reckon we could both write the code in a minute or
so that allows the inclusion of a boolean flag parameter
to the TLV parsing subroutine.

Regards,
Charlie P.

ext Justin Dean wrote:
>> With 3 this was introduced to avoid confusion on which value should be
>>     
> used.
>