Subject: [manet] NHDP "Hello" packet too big

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

Hello folks,

Here is some text that I wrote up at the last IETF
to compare the existing NHDP message to a smaller
format, roughly taken from the SMURF protocol
specification with some more fields added so that it
would have additional functionality as specified by
NHDP.  The bottom line:

NHDP example in Appendix A: 50 bytes

SMURF-like packet format: 14 bytes

TLV version of SMURF-like format: 15 bytes.

Plus the NHDP overhead will get worse as more
neighbors are counted.  This is important because
the example shown has only 4 neighbors, and for
good connectivity it is usually recommended to have
at least 6 (or 5.7 or something like that).  For a lot
of published papers (maybe even most of them),
the number of neighbors is quite a bit higher.

I would like to suggest that either that we
encourage the development of some alternative
HELLO packet format, or else that the basic
NHDP format should be substantially revised.

Here is my text with examples, derived from
Appendix A of NHDP:
=====================================
   octet) addresses without prefix TLVs.  The message is transmitted
   with a full message header (message semantics octet is 0) with a hop
   limit of 1 and a hop count of 0.  The overall message length is 50
   octets.

   The message contains a message TLV block with content length 8 octets
   containing two message TLVs, of types VALIDITY_TIME and
   INTERVAL_TIME.  Each uses a TLV with semantics value 8, indicating
   that no start and stop indexes are included, and each has a value
   length of 1 octet.  The values included (0x68 and 0x50) are time
   codes representing the default values of parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the
   default value of constant C (0.0625 second).

   The first address block contains 1 local interface address.  The
   semantics octet value 2 indicates no address tail, and the head
   length of 4 octets indicates no address mid sections.  This address
   block has no TLVs (TLV block content length 0 octets).

   The second, and last, address block contains 4 neighbor interface
   addresses.  The semantics octet value 2 indicates no address tail,
   the head length of 3 octets indicates address mid sections of one
   octet each.  The following TLV block (content length 7 octets)
   includes one LINK_STATUS TLV which reports the link status values of
   all reported neighbors in a single multivalue TLV: the first two
   addresses are HEARD, the third address is SYMMETRIC and the fourth
   address is LOST.  The TLV semantics value of 40 indicates, in
   addition to that this is a multivalue TLV, that no start and stop
   indexes are included, since values for all addresses are included.
   The TLV value length of 4 octets indicates one octet per value per
   address.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
full message header (message semantics octet is 0)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     HELLO     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

hop limit of 1 and a hop count of 0:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The message contains a message TLV block with content length 8 octets
   containing two message TLVs, of types VALIDITY_TIME and
   INTERVAL_TIME.  Each uses a TLV with semantics value 8, indicating
   that no start and stop indexes are included, and each has a value
   length of 1 octet.  The values included (0x68 and 0x50) are time
   codes representing the default values of parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the
   default value of constant C (0.0625 second).
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     | VALIDITY_TIME |0 0 0 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     | INTERVAL_TIME |0 0 0 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first address block contains 1 local interface address.  The
semantics octet value 2 indicates no address tail, and the head
length of 4 octets indicates no address mid sections.  This address
block has no TLVs (TLV block content length 0 octets).
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|                     Head                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |
     +-+-+-+-+-+-+-+-+

   The second, and last, address block contains 4 neighbor interface
   addresses.  The semantics octet value 2 indicates no address tail,
   the head length of 3 octets indicates address mid sections of one
   octet each.
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1|             Head              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |      Mid      |      Mid      |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Mid      |
     +-+-+-+-+-+-+-+-+

                The following TLV block (content length 7 octets)
   includes one LINK_STATUS TLV which reports the link status values of
   all reported neighbors in a single multivalue TLV: the first two
   addresses are HEARD, the third address is SYMMETRIC and the fourth
   address is LOST.  The TLV semantics value of 40 indicates, in
   addition to that this is a multivalue TLV, that no start and stop
   indexes are included, since values for all addresses are included.
   The TLV value length of 4 octets indicates one octet per value per
   address
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|  LINK_STATUS  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 1 0 1 0 0 0|0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   SYMMETRIC   |     LOST      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alternative layout    [14 bytes]
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     HELLO     | flags |#Selves|#Heard | #Sym  | #Lost | Seq#  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Originator Address(es)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Head                      |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Mid      |      Mid      |   ..... extensions  ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or, new TLV def "Hello data element"  [15 bytes = 5 bytes + 10 bytes data]
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type=HELLO   |     Length    | flags |#Selves|#Heard | #Sym  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | #Lost | Seq#  |   ..... data  ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where, "data" is as follows:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Originator Address(es)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Head                      |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Mid      |      Mid      |   ..... extensions  ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=====================================

Regards,
Charlie P.

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

---

From: "Justin Dean" <[email-masked]>
Date: Mon, 13 Aug 2007 11:38:32 -0400

First thank you for this example.  There are a few things I would like to
try and clear up and having a solid example will help me do that.

First the two samples you are including do not include the same information.
Particularly using full message header semantics and the addition of the
hold and validity times.  If we are to compare the two packet formats
suggested they should contain the same information and packetbb allows you
to do this.

By only including the information included in your smurf-like packet 
|      Mid      |      Mid      |

Hop count and ttl values in the packetbb message header are not needed and
they can be turned off using the semantics bits.  A 2 byte savings.
Validity time and Hold time values are required per NHDP but that's not a
packetbb issue so we can remove those as well.  An 8 byte savings.  (note 2
bytes are still required to set the tlv field to 0).  Also one example had 3
addresses an the other 4. A 2 byte savings (mid and tlv linktype) The rest
of the information has to be included so that's 38 bytes down from 50 which
is still MUCH larger than 14-15.  However there are, in my opinion, quite a
few VERY limiting features of the suggested alternative.  

The #of any give type of neighbor is limited to a max of 15.  If there are
more than 15 symmetric neighbors it can't convey that information.  A simple
"fix" would be to increase the size to 1 fully octet for each field with a
flag.  The assumption of a 3 byte head and 1 byte tails may not always hold
true, again a "fix" could be to use 2 more bits of your flags to allow the 4
different methods but then what about ipv6 support.  The included seq# space
is again 15.  While this may be sufficient for the requirements you are
envisioning it would not be sufficient for a large portion of possible
protocols which I envision using packetbb.  Which brings me to my main
point.  This packet format is designed to work very well for ONE protocol
not many different possible protocols.  Many types of information can not be
included without modification of the smurf-like packet format.  Information
such as; including multiple message types in the same packet (possibly from
even differing protocols), including "other" semi standard information such
as ttl, hopcount, conveying node information such as willingness, conveying
address specific information such as a metric, or mpr status.  Packetbb can
do all of these things natively without change to the document or packet
layout, while supporting a wide range of possible protocol requirements.
The alternative as I hope I have demonstrated becomes messy and larger if
these things would be incorporated. 

I would also like to point out how things might grow byte wise in terms of
packetbb as this example is a pretty worst case situation.  Each new address
added to the packetbb format, assuming no new neighbor types and similar
headers, would add 2 bytes for each address without changing how the link
status tlvs are being used.  At some point (didn't do the math right now)
using 3 different tlvs with indexes would become more efficient than
including 1 byte for each address in the tlv.  After this point each
additional address would only add one byte of overhead.  Also oftentimes the
only type of address being included in a hello message after the initial
startup is symmetric which would require a 6 bytes (3 less than the given
example here when using 4 addresses!) to convey for any number of addresses
(if they are all symmetric).

The main thing though is the flexibility of the format.  The cost in terms
of bytes is in my opinion worth it its not orders or magnitude greater.
Discussions about a totally different packet format designed around specific
protocol requirements with little flexibility are in my opinion not that
helpful.  Suggested changes to improve compactness while maintaining
flexibility is.

Justin

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: Thursday, August 09, 2007 7:55 PM
To: Manet
Subject: [manet] NHDP "Hello" packet too big

Hello folks,

Here is some text that I wrote up at the last IETF to compare the existing
NHDP message to a smaller format, roughly taken from the SMURF protocol
specification with some more fields added so that it would have additional
functionality as specified by NHDP.  The bottom line:

Plus the NHDP overhead will get worse as more neighbors are counted.  This
is important because the example shown has only 4 neighbors, and for good
connectivity it is usually recommended to have at least 6 (or 5.7 or
something like that).  For a lot of published papers (maybe even most of
them), the number of neighbors is quite a bit higher.

I would like to suggest that either that we encourage the development of
some alternative HELLO packet format, or else that the basic NHDP format
should be substantially revised.

Here is my text with examples, derived from Appendix A of NHDP:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 full
message header (message semantics octet is 0)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     HELLO     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first address block contains 1 local interface address.  The semantics
octet value 2 indicates no address tail, and the head length of 4 octets
indicates no address mid sections.  This address block has no TLVs (TLV
block content length 0 octets).
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|                     Head                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |
     +-+-+-+-+-+-+-+-+

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 13 Aug 2007 15:18:21 -0700

Hello Justin,

You are right that the examples do not contain the same information,
and I agree with many points of your analysis.  A few other comments
below...

ext Justin Dean wrote:
> packetbb issue so we can remove those as well.
I would suggest that these values not be sent in every Hello message.
I'd rather (a) have default values and (b) allow nodes to send the values
out only occasionally as desired.  I know that there are not any
universally valid values for the timers, but that hasn't stopped other
protocols from having default values anyway.
> The #of any give type of neighbor is limited to a max of 15.
Yes.  That is O.K., because graphs with more than 15 neighbors are 
pretty dense
graphs.  I like dense graphs too, but minimal systems will endeavor to 
avoid them
and we should allow parsimonious operation while still allowing for more 
general
operation as well.  We can allow for more neighbors in several easy 
ways.  For
instance the same TLV could be entered multiple times.
>   If there are
> flag.
I don't think that is needed for the common cases, though.
>    ...             Which brings me to my main
> not many different possible protocols.
I did not mean to say that the message format that I indicated was
the final answer -- far from it.  In fact, it was just the product of an
hour's work, or two, motivated at the IETF as I finally had made
time to read NHDP.  I think this is important because neighborhood
discovery messages can be a major source of congestion, especially
if they are broadcast (thus, no RTS/CTS).
>   Many types of information can not be
The packet format as presented is equally amenable to extensions as
packetbb is.  In fact, the quickie "TLV" format could be wrapped up
in packetbb, and still maintain almost all of the savings.
> including 1 byte for each address in the tlv.
... I am pretty sure this isn't right.  Unless I am missing your point...
I think the difference is that I am assigning counts for the kinds of
address information contained in the neighborhood information, and
then a list of addresses as indicated by the count fields.  There would
only have to be one tlv for all of this.  Then it is a matter of how to
define the contents (and semantics) of the "v" part of the tlv.
>   After this point each
So we could have a flag to control the presence of some of the other
fields.  This would be fine with me, as you may guess.
> of bytes is in my opinion worth it its not orders or magnitude greater.
I hope you are exaggerating.  Surely a 190 byte packet is far
less preferable than a 20 byte.  On the other hand, some people
define "order of magnitude" to be only a factor of three, or else
sqrt(10), sigh.  But, to the point, I think that going from 38 down
to 15 is pretty good and worthwhile.

Alternatively, we could have the NHDP format and a
"streamlined" format that would be useful for implementations
where size matters.
> helpful.
I think that with some fine tuning I could turn my quickie
suggestion into a format that has equal flexibility and functionality
as the given NHDP format.  What I presented was really for the
purpose of jump-starting the discussion.
>   Suggested changes to improve compactness while maintaining
> flexibility is.
>   
Please try to see my current recommendation in exactly that light.

Regards,
Charlie P.

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 14 Aug 2007 06:55:54 +0200

Charlie,

Please see comments embedded below.

On Aug 14, 2007, at 12:18 AM, Charles E. Perkins wrote:

>> By only including the information included in your smurf-like  
>> packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
>> +-+-+

So just to understand what you are suggesting, you want to specify  
"absent a VALIDITY_TIME TLV, the validity time for information  
contained in a HELLO message is XX seconds" -- same for Interval time?

> graphs.  I like dense graphs too, but minimal systems will endeavor  
> to avoid them
> and we should allow parsimonious operation while still allowing for  
> more general

Sorry, you lost me. What TLV are you talking about that you want to  
include multiple times? Assuming that you do not mean "TLV" but  
"block of bits in your previous ascii-diagram", then I'll then say  
that in case where you have more than 15 addresses in your message,  
your suggested scheme is not optimal in that (i) it doesn't allow for  
optimal aggregation and (ii) a lot of information is repeated. I  
point out that intelligent use of packetbb will allow you to not  
repeat information and attain optimal aggregation.

In Packetbb, TLVs are associated to addresses and express information  
about addresses, they do not contain addresses. The above ascii-art  
that your original message contained does not suggest any TLVs present.

Maybe I am missing something fundamental from what you're suggesting,  
but I do not see the benefit of it.

> I don't think that is needed for the common cases, though.

Nonetheless, Charlie, I *have* situations where I need to report >15  
addresses, and I *want* to be able to do so without having to resort  
to hacks and patches. Why? Because hacks and patches increase the  
code complexity and code footprint and parsing complexity.

Not to mention the requirements to verify many different parsing and  
encoding algorithms -- something which I know that at least some  
people are VERY concerned about, especially in embedded devices. (I'm  
concerned too...although for me, it's simply because it's easier to  
write correctly and test one general block of code than it is to  
write a dozen or so different ones for a given protocol. In a  
different email I stated how the use of packetbb substantially  
reduced the code footprint of OLSRv2 vs OLSR)

Notice that NHDP messages are based on packetbb, and that packetbb is  
designed for a much larger scope than just nhdp. For example. OLSRv2  
and DYMO. In at least OLSRv2, I know of common scenarios where I want  
to transmit >15 addresses in a message. And, I want to be able to do  
so without having to have to write a special parser/parsing logic,  
but rather use the same as in NHDP....and DYMO...or otherwise said,  
as specified in packetbb.

I know that you consider saving a bit here and there as more  
important than being able to reduce the code footprint and/or  
processing complexity, but as we discussed in Chicago, there're  
conflicting requirements and I feel that packetbb (and, thus, NHDP)  
represents a decent compromise.

> if they are broadcast (thus, no RTS/CTS).

And, as I also pointed out in Chicago, FLOODING is the major source  
of congestion in MANETs, and in comparison to FLOODING, any overhead  
by a HELLO protocol is noise. Thus, the prime task is to reduce the  
overhead of conducting a flooding operation. I believe that SMF and  
even your own efforts in SMURF indicate that you share this opinion?  
Second task is to reduce the number of flooding operations required  
by a protocol. Doing those two is, in my experience, the  
overwhelmingly largest and most important part of MANET protocol design.

Reducing the size of a given message by a few tens of octets or an  
order of magnitude isn't really buying much, if anything at all.  
Experience shows that the MAC overhead and the MAC contention [with  
most/all MACs I know] is the bigger cost than the payload of a  
transmission, and so that actually when making a transmission,  
stuffing s much useful information into that transmission is  
beneficial. Hence, the multi-message packet format of packetbb.

Here's an example of a real test I ran: running OLSR with "minimal"  
link state information in the TC messages vs. with "full" link state  
information in the TC messages (the avg. TC message size difference  
was 1:2.4) doesn't make a significant dent in the performance of a 50  
node network in the real world. This was over basic 802.11 cards, btw.

It does make a difference in a simulation or analysis, when you're  
counting octets of overhead. It doesn't  make a difference in the  
real world when you're concerned with getting data traffic from a to  
b, it doesn't in this test.

These statements are, btw., based on experience from actually  
building and running MANETs (and are backed up by analysis and  
simulation, but that's an aside, what's interesting is how things  
actually run).

<SNIP>

> Please try to see my current recommendation in exactly that light.

Charlie, I appreciate your effort but I am not able to see your  
recommendation in that light....because.......it's not.

As you'll note, numerous suggestions and comments have been taken on  
board and have made their way into packetbb: modular message headers  
(that was suggested by yourself), head:mid:tail rather than head:tail  
(that was initiated by Simone, I think, refined by Chris), optional  
packet headers and packet TLV (you + Satoh-san), to name a few. These  
all added some savings on the expense of slightly more complex  
parsing code --  without impeding on the format flexibility and  
within the general format/paradigm being discussed.

Just to recapitulate (a 3-second run-down), the general format/ 
paradigm is: message header scopes distribution. addresses are  
expressed in aggregated address blocks. Attributes of addresses are  
expressed as TLVs associated to identified addresses. The suggestions  
above -- which are welcome and which we are grateful to you and  
others for having made -- helped improve and refine packetbb to its  
current form

What you're proposing now is not a "suggestion to improve compactness  
while maintaining flexibility" (to cite Justin), but is to scrap  
essentially all of packetbb, which has been developed carefully over  
 >2 years by the MANET wg (including you, as indicated above and in  
previous emails), implemented by numerous independent parties, fine- 
tuned over those two years to allow for address aggregation in an  
efficient way, flexibility in an efficient way, reasonably straight- 
forward AND general parsing logic, verified to satisfy the  
requirements of multiple parties and WGLCed ..... in favor of a yet- 
to-be-specified-and-fine-tuned, not implemented, not evaluated format  
which has as-yet undetermined features and flexibility.

That, to me, is an easy choice to make. I second 100% what Justin  

> protocol requirements with little flexibility are in my opinion not  

Cheers,

Thomas

---

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

Hello again Thomas,

You are making me work very hard today.

> contained in a HELLO message is XX seconds" -- same for Interval time?
 That would be the formulation for a default value, yes.
 
> include multiple times? Assuming that you do not mean "TLV" but "block 
> of bits in your previous ascii-diagram",

 Well, I did make a TLV-oriented formulation in my previous
email...  see below
 
> then I'll then say that in case where you have more than 15 addresses 
> in your message, your suggested scheme is not optimal in that (i) it 
> doesn't allow for optimal aggregation and (ii) a lot of information is 
> repeated. I point out that intelligent use of packetbb will allow you 
> to not repeat information and attain optimal aggregation.
 O.K.  If you feel strongly about this, then we should have a "small" 
version
and a "big" version.  I suggest that the overhead from duplicated TLVs
for the "small version" is still quite small in comparison with the 
"big" version.
 
> that your original message contained does not suggest any TLVs present.

 Here it is again, from my first message.  But please note that this 
needs some more
tuning in order to duplicate all the functionality in NHDP -- if, in 
fact, all of the
functionality is needed.  However, I am not debating that issue just 
right here...

> ... new TLV def "Hello data element"  [15 bytes = 5 bytes + 10 bytes data]
===========================================================================
> but I do not see the benefit of it.
It is just the benefit of eliminating over half of the overhead from the
NHDP formulation.

> to hacks and patches. Why? Because hacks and patches increase the code 
> complexity and code footprint and parsing complexity.
 Please, Thomas, be nice.  I don't call your designs hacks and patches.
I remember from my days at IBM a lot of analogies about kicking dead
whales down the beach, but I am really avoiding making any such
analogies here.

> so without having to have to write a special parser/parsing logic, but 
> rather use the same as in NHDP....and DYMO...or otherwise said, as 
> specified in packetbb.
 I think what you are saying is that we have to be constantly on guard, 
because
packetbb is liable to substantially increase the packet overhead for any 
design
that isn't sufficiently "like" OLSR.

When do I begin to get more scared and go into panic mode?
 
>
> I know that you consider saving a bit here and there as more important 
> than being able to reduce the code footprint and/or processing 
> complexity, but as we discussed in Chicago, there're conflicting 
> requirements and I feel that packetbb (and, thus, NHDP) represents a 
> decent compromise.
 Well, I don't think so, pure and simple.  I mean, jeez, more than 
_double_ the
packet size??!!
 
> And, as I also pointed out in Chicago, FLOODING is the major source of 
> congestion in MANETs,
 I certainly agree with this.  Furthermore, I suggest that the small 
packet size
does not in any way reduce the applicability of the protocol.
 
> and in comparison to FLOODING, any overhead by a HELLO protocol is noise.
 I do NOT agree with this.
 
> Thus, the prime task is to reduce the overhead of conducting a 
> flooding operation. I believe that SMF and even your own efforts in 
> SMURF indicate that you share this opinion? Second task is to reduce 
> the number of flooding operations required by a protocol. Doing those 
> two is, in my experience, the overwhelmingly largest and most 
> important part of MANET protocol design.
 In fact, our follow-on work has indicated that the performance of
the protocols really, _really_ depends on HELLO intervals and
neighborhood sizes.  When MAC-layer acknowledgements can
eliminate some of the need for the functionality of a HELLO message,
we can see the benefit.

I am not prone to make such extreme statements as you are in
the recent notes, but I do believe that local neighborhood advertisements
matter and that size matters.  For just one reason, broadcast damages
throughput for hidden terminals which are not detected by the
sender (and won't be for the foreseeable future in 802.11-land).
It is a matter of interest to find out all of the other reasons, but
I disagree with your manner of dismissing them out of hand.
 
> beneficial. Hence, the multi-message packet format of packetbb.
 I didn't want to get into the issues of reducing packet
size for the routing protocol here, sigh...
 
> counting octets of overhead. It doesn't  make a difference in the real 
> world when you're concerned with getting data traffic from a to b, it 
> doesn't in this test.
>
> These statements are, btw., based on experience from actually building 
> and running MANETs (and are backed up by analysis and simulation, but 
> that's an aside, what's interesting is how things actually run).
 I can fully believe you in an unloaded network.  However, bigger 
packets more
quickly drive a network into congestive behavior, and more quickly use up
battery power.  Whether the effect is 10%, 20%, or more is system-dependent.
We agree on many points -- for instance, that flooding is the main 
culprit, and
that sending multiple packets is to be avoided when one medium access can do
the same job.  I guess I ought to be happy for at least that much.

In the meantime, I'll try to use small packets as rarely as possible to
achieve results that in every way help to avoid flooding.

> recommendation in that light....because.......it's not.  
 Thomas -- it IS!

> essentially all of packetbb,
 No!  I am proposing to maintain the address TLV structure, and
construct a TLV that contains data needed for maintaining
neighborhood structures.
 
> which has been developed carefully over >2 years by the MANET wg 
> (including you, as indicated above and in previous emails), 
> implemented by numerous independent parties, fine-tuned over those two 
> years to allow for address aggregation in an efficient way, 
> flexibility in an efficient way, reasonably straight-forward AND 
> general parsing logic, verified to satisfy the requirements of 
> multiple parties and WGLCed ..... in favor of a 
> yet-to-be-specified-and-fine-tuned, not implemented, not evaluated 
> format which has as-yet undetermined features and flexibility.
 You are comparing packetbb to SMURF here.  I am comparing NHDP to
SMURF.  Perhaps NHDP exposes the tendency for packetbb designs to
split every last data item into separate TLVs (which causes huge overhead).
That is some matter of concern, but it isn't absolutely necessary to misuse
packetbb in that way, and I would hope this particular discussion could be
taken as a case in point.

Furthermore, I wish you would not use such extreme language.
We had submitted SMURF a while back, and were told that we were not
doing that stuff in [manet] at that time.  Your name was on that document.
I didn't press the point, and then NHDP happened, presumably influenced
by packetbb which was itself undergoing steady evolution.  SMURF uses
MPRs (a known technique) and the INRIA algorithm with which you are
very familiar.  The fine-tuning has to do with things that need fine-tuning
in NHDP also -- like time-outs and so on.  Plus we should discuss how
much it matters about whether two-hop link information has to be segregated
into symmetric vs. non-symmetric varieties.  But if it matters, it will be a
simple matter to use the algorithm already presented in NHDP to do this
work.

I really think there is a middle ground here and see no reason that we
cannot step into it.
 
>
> That, to me, is an easy choice to make. I second 100% what Justin said 
> in his email:
 Solidarity is good, sometimes...
 
>> protocol requirements with little flexibility are in my opinion not that
 I guess flexibility is in the eye of the beholder.  Adding 20 kg to a 
soldier's
backpack may increase flexibility at the price of endurance.

Regards,
Charlie P.