Subject: [manet] Compressed TC and Hello message headers

From: "Teco Boot" <[email-masked]>
Date: Wed, 22 Apr 2009 17:42:36 +0200

A repeating comment on PacketBB was the large overhead for signaling only a single bit or octet with separate TLVs. I think we can repair some of this. Below a proposal for more compact TC and Hello message headers. I used PacketBB syntax for describing the headers.
There is no impact on the protocols itself. It is just syntax. If accepted, drafts need some rewording.

Comments?

Teco.

OLSRv2 - TC message header:
===========================

<TC-header> is defined by:

   <TC-header> := <TC-flags>
                  <TC-ANSN>
                  <TC-Interval>?
                  <TC-Validity>?

where:

   <TC-flags>  is a 8-bit field, specifying the interpretation of the
      remainder of the TC-header:

      bit 0 (Incomplete):  If cleared ('0'), then the TC message is 
         complete.  If set ('1'), then TC message is incomplete.

      bit 1 (TChasInterval):  If cleared ('0'), then <TC-Interval> is not
         included in the <TC-header>.  If set ('1'), then <TC-Interval>
         is included in the <TC-header>.

      bit 2 (TChasValidity):  If cleared ('0'), then <TC-Validity> is not
         included in the <TC-header>.  If set ('1'), then <TC-Validity>
         is included in the <TC-header>.

      bits 3-7:  Are RESERVED and SHOULD each be cleared ('0') on
         transmission and SHOULD be ignored on reception.

The example in OLSRv2 Appendix E would change from:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| INTERVAL_TIME |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|     Value     | VALIDITY_TIME |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|     Value     | CONT_SEQ_NUM  |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 0|         Value (ANSN)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

to:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|   TC_HEADER   |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 1|   TC-flags    |           TC-ANSN             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  TC-Interval  |  TC-Validity  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLVs size is decreased from 13 to 8 octets (-38%). And there are 5 spare flag bits.

NHDP - Hello message header:
============================
 
<H-header> is defined by:

   <H-header> := <H-flags>
                 <H-Validity>
                 <H-Interval>?

where:

   <H-flags>  is a 8-bit field, specifying the interpretation of the
      remainder of the H-header:

      bit 0 (HhasInterval):  If cleared ('0'), then <H-Interval> is not
         included in the <H-header>.  If set ('1'), then <H-Interval>
         is included in the <H-header>.

      bits 1-7:  Are RESERVED and SHOULD each be cleared ('0') on
         transmission and SHOULD be ignored on reception.

The example in Appendix C would change from:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

to:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|   H_HEADER    |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|    H-flags    |   H-Validity  |   H-Interval  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLVs size is decreased from 8 to 6 octets (-25%). And there are 7 spare flag bits.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 22 Apr 2009 17:53:20 +0200

On Mittwoch 22 April 2009 17:42:36 Teco Boot wrote:
> A repeating comment on PacketBB was the large overhead for signaling only a
> single bit or octet with separate TLVs. I think we can repair some of this.
> Below a proposal for more compact TC and Hello message headers. I used
> PacketBB syntax for describing the headers. There is no impact on the
> protocols itself. It is just syntax. If accepted, drafts need some
> rewording.
>
> Comments?

> TC...

> Hello...
I don't think this is a good idea.

You gain a few bytes (constant, not per hello/tc address entry) and loose 
parts of the flexibility of PacketBB.

It's just 5/2 bytes... of potential hundreds of bytes of the message. So it's 
no big gain.

PacketBB can be easily parsed by a SAX-style parser, just add a listener for 
every TLV you are interested in. We would loose this if we start got back to 
the binary syntax.

What if we want to add another variable to your header ? We would loose 
backward compatiblity, because older versions don't know they have to skip a 
byte (or a few bytes) if the corresponding bit is set.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 22 Apr 2009 18:04:08 +0200

Hi,

I completely agree with Henning. While the gain is relatively small
(consider non-empty-HELLOs using IPv6 could be several hundreds of bytes
long), we lose all flexibility of packetbb. As Henning said, one big
advantage of packetbb is that it allows a large flexibility while in the
same time keeping backwards compatibility.

Ulrich

On Wed, Apr 22, 2009 at 5:53 PM, Henning Rogge <[email-masked]>wrote:

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 22 Apr 2009 20:43:08 +0200

I agree fully with Henning and Ulrich on this matter: a small gain at  
a huge loss in flexibility is not a trade-off that I think appropriate.

Thomas

On Apr 22, 2009, at 18:04 PM, Ulrich Herberg wrote:

> (consider non-empty-HELLOs using IPv6 could be several hundreds of  
> bytes long), we lose all flexibility of packetbb. As Henning said,  
> one big advantage of packetbb is that it allows a large flexibility  
> while in the same time keeping backwards compatibility.
>
> Ulrich
>
> On Wed, Apr 22, 2009 at 5:53 PM, Henning Rogge  
> <[email-masked]> wrote:
> > TLVs size is decreased from 13 to 8 octets (-38%). And there are  
> 5 spare
> > flag bits.
>
> > Hello...
> > TLVs size is decreased from 8 to 6 octets (-25%). And there are 7  
> spare
> > flag bits.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 22 Apr 2009 21:56:22 +0200

Hi Henning, Ulrich and Thomas,

I fully agree: the proposal is a small gain.
Dutch saying: "wie het kleine niet eert, is het grote niet weerd".
This means: "who refuses what's small, doesn't deserve what's big".
By the way, we had discussions on few octets before. And keep in mind the TC header may appear in a packet many times. And TCs would be small if topology reduction works fine.

I strongly disagree with "huge loss in flexibility", because it is incorrect. But yes, it is time to carefully verify what function is mandatory and what is not. When the std is published, all additions are optional. We can use spare flags (to be ignored on reception by nodes that doesn't support the option) or a new TLVs. Why do you think my suggestion blocks any of this ??

I do not understand Hennings parsing argument. Packet and message header are parsed exactly as what I suggest for TC and Hello headers. So parsing logic is already there. And the header fields must be supported, so all implementations must parse it.
Yes, I think we should not add optional header fields and indicate this with flags. Same comment applies for RFC5444, so nothing new here. 

Comment on Ulrich his statement that IPv6 hellos are "long". There is no reason for this, as packetBB can compress IPv6 to the same length as IPv4 IDs. It is a matter of addressing scheme. This area is my day to job (or struggle..) in real world ad hoc networks. I may need IPv6 for good reasons. And I definitely need efficient transport of data, also for good reasons. My split mind: unique addresses by nature (random, EUI-64, etc.) are great for reducing network management efforts, but at the same time the addresses are hard to compress. This is one of the reasons I am working on RouterIDs, msgs will be compact as long as the RouterIDs and delegated prefixes can be compressed. This is doable.

Please think again on the proposal. I know it is a small gain. But still: it is gain. There is no disadvantage. Not at all !!

Teco.

NB. 
I corrected TC-header. TC-Validity is always there so flag is not needed. See adjusted proposal below.

===========

Van: [email-masked] [mailto:[email-masked]] Namens Thomas Heide Clausen
Verzonden: woensdag 22 april 2009 20:43
Aan: Ulrich Herberg
CC: [email-masked]
Onderwerp: Re: [manet] Compressed TC and Hello message headers

I agree fully with Henning and Ulrich on this matter: a small gain at a huge loss in flexibility is not a trade-off that I think appropriate.

Thomas

Hi,

I completely agree with Henning. While the gain is relatively small (consider non-empty-HELLOs using IPv6 could be several hundreds of bytes long), we lose all flexibility of packetbb. As Henning said, one big advantage of packetbb is that it allows a large flexibility while in the same time keeping backwards compatibility.

Ulrich
On Wed, Apr 22, 2009 at 5:53 PM, Henning Rogge <[email-masked]> wrote:

Henning Rogge

                  <TC-Validity>
                  <TC-Interval>?

where:

      bits 2-7:  Are RESERVED and SHOULD each be cleared ('0') on
         transmission and SHOULD be ignored on reception.

      0                   1                   2                   3

to:

      0                   1                   2                   3
     |  TC-Validity  |  TC-Interval  |

 

   <H-header> := <H-flags>
                 <H-Validity>
                 <H-Interval>?

where:

      0                   1                   2                   3

to:

      0                   1                   2                   3

---

From: Henning Rogge <[email-masked]>
Date: Thu, 23 Apr 2009 07:56:48 +0200

Am Wednesday 22 April 2009 21:56:22 schrieb Teco Boot:
> By the way, we had discussions on few octets before. And keep in mind the
> TC header may appear in a packet many times. And TCs would be small if
> topology reduction works fine.
>
> I strongly disagree with "huge loss in flexibility", because it is
> incorrect. But yes, it is time to carefully verify what function is
> mandatory and what is not. When the std is published, all additions are
> optional. We can use spare flags (to be ignored on reception by nodes that
> doesn't support the option) or a new TLVs. Why do you think my suggestion
> blocks any of this ??
>
> I do not understand Hennings parsing argument. Packet and message header
> are parsed exactly as what I suggest for TC and Hello headers. So parsing
> logic is already there. And the header fields must be supported, so all
> implementations must parse it. Yes, I think we should not add optional
> header fields and indicate this with flags. Same comment applies for
> RFC5444, so nothing new here.
A change of RFC5444 and a change of NHDP/OLSRv2 messages is something 
completely different. PacketBB messages with additional fields can be EASILY
read by old versions of OLSR, because the TLV headers contain the necessary 
information to skip unknown fields. Compress them into a bitfield plus a 
number of binary values and you can only do this if you have knowledge about 
he length of the fields represented by each bit. There is a reason why 
packetbb lost a number of header fields and corresponding control bits (they 
will be represented as TLV fields).

An example...

you define your "compressed" TC header this way:
   <TC-header> := <TC-flags>
                  <TC-ANSN>
                  <TC-Interval>?
                  <TC-Validity>?

This is already a problem for packetbb readers because they need knowledge 
about the internal structure of the TC header to display the values and parse 
the following address block. One of the great things of packetbb is that you 
can parse a message WITHOUT knowing anything about the semantic of the 
messages.

But let's say we do it your way, and later we decide we need a new field in 
the header called <TC-Range>, which is two byte in length.

The new header would look like
   <TC-header> := <TC-flags>
                  <TC-ANSN>
                  <TC-Interval>?
                  <TC-Validity>?
                  <TC-Range>?

Because the old parser don't know about the additional used bit in the 
<TC-flags> field and don't know about the length (or even existence) of the 
new <TC-Range> field, they cannot parse this message ! Some of the old parsers 
will even ignore the bit and mix up the <TC-Range> field with the beginning of 
an address block !

> Comment on Ulrich his statement that IPv6 hellos are "long". There is no
> reason for this, as packetBB can compress IPv6 to the same length as IPv4
> IDs. It is a matter of addressing scheme. This area is my day to job (or
> struggle..) in real world ad hoc networks. I may need IPv6 for good
> reasons. And I definitely need efficient transport of data, also for good
> reasons. My split mind: unique addresses by nature (random, EUI-64, etc.)
> are great for reducing network management efforts, but at the same time the
> addresses are hard to compress. This is one of the reasons I am working on
> RouterIDs, msgs will be compact as long as the RouterIDs and delegated
> prefixes can be compressed. This is doable.
Sometimes you want RouterIDs, sometimes you don't want them because you run an 
simple autoconfiguration protocol. But 3-5 bytes is still very small compared 
to the whole OLSR message.

> Please think again on the proposal. I know it is a small gain. But still:
> it is gain. There is no disadvantage. Not at all !!
Yes, there is...

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: [email-masked]
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 23 Apr 2009 08:51:35 +0200

Hi,

I had already written a long reply to that when I saw that Henning covered
most of my arguments. :-) So I will not repreat them, just strongly agree
with them.

On Wed, Apr 22, 2009 at 9:56 PM, Teco Boot <[email-masked]> wrote:

> [...]
> IDs. It is a matter of addressing scheme.

Well, as you say, this depends very much on the addressing scheme. But even
if you use IPv6 addresses that can be well compressed, still the fact stays
that your proposal saves a (small) *constant* number of bytes. The savings
are not growing with the number of addresses in the message. So your
percentages from your previous email are not correct.

> This area is my day to job (or struggle..) in real world ad hoc networks. I
> may need IPv6 for good reasons. And I definitely need efficient transport of
> data, also for good reasons. My split mind: unique addresses by nature
> (random, EUI-64, etc.) are great for reducing network management efforts,
> but at the same time the addresses are hard to compress. This is one of the
> reasons I am working on RouterIDs, msgs will be compact as long as the
> RouterIDs and delegated prefixes can be compressed. This is doable.
>

As Henning said, small gain, high disadvantage.

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Apr 2009 09:06:41 +0200

Hi Henning,

I think you still misunderstand the proposal.

Currently, there is no standard for OLSRv2 and thus there is no compliant implementation. Backwards compatibility is no problem yet. It will be soon. All compliant NHDP and OLSRv2 implementations MUST be able to handle the suggested TC and H header. There is no "unknown" condition.

The TC-header and H-header are just TLVs. PacketBB readers do not have to know the internal structure of a TLV value. Not now and not in my proposal. "sub-parsing" the headers for packet header, message header and the suggested TC and H headers is very similar. This is what I mentioned already, the rules for adding new sub-fields would be "not allowed". Nothing new here.

Out of topic, but on RouterID: selecting a RouterID when using whatever address configuration mechanism is not a problem. Just pick a unique address. Prefer an address that can be compressed with address block TLVs. Prefer a stable address. Some requirements are challenging, like privacy (change all addresses on the flight, including RouterID).

Regards, Teco

|-----Oorspronkelijk bericht-----
|Van: Henning Rogge [mailto:[email-masked]]
|Verzonden: donderdag 23 april 2009 7:57
|Aan: [email-masked]
|CC: Teco Boot; 'Thomas Heide Clausen'; 'Ulrich Herberg'
|Onderwerp: Re: [manet] Compressed TC and Hello message headers
|
|Am Wednesday 22 April 2009 21:56:22 schrieb Teco Boot:
|> Hi Henning, Ulrich and Thomas,
|>
|> I fully agree: the proposal is a small gain.
|> Dutch saying: "wie het kleine niet eert, is het grote niet weerd".
|> This means: "who refuses what's small, doesn't deserve what's big".
|> By the way, we had discussions on few octets before. And keep in mind
|the
|> TC header may appear in a packet many times. And TCs would be small if
|> topology reduction works fine.
|>
|> I strongly disagree with "huge loss in flexibility", because it is
|> incorrect. But yes, it is time to carefully verify what function is
|> mandatory and what is not. When the std is published, all additions
|are
|> optional. We can use spare flags (to be ignored on reception by nodes
|that
|> doesn't support the option) or a new TLVs. Why do you think my
|suggestion
|> blocks any of this ??
|>
|> I do not understand Hennings parsing argument. Packet and message
|header
|> are parsed exactly as what I suggest for TC and Hello headers. So
|parsing
|> logic is already there. And the header fields must be supported, so
|all
|> implementations must parse it. Yes, I think we should not add optional
|> header fields and indicate this with flags. Same comment applies for
|> RFC5444, so nothing new here.
|A change of RFC5444 and a change of NHDP/OLSRv2 messages is something
|completely different. PacketBB messages with additional fields can be
|EASILY
|read by old versions of OLSR, because the TLV headers contain the
|necessary
|information to skip unknown fields. Compress them into a bitfield plus a
|number of binary values and you can only do this if you have knowledge
|about
|he length of the fields represented by each bit. There is a reason why
|packetbb lost a number of header fields and corresponding control bits
|(they
|will be represented as TLV fields).
|
|An example...
|
|you define your "compressed" TC header this way:
|   <TC-header> := <TC-flags>
|                  <TC-ANSN>
|                  <TC-Interval>?
|                  <TC-Validity>?
|
|This is already a problem for packetbb readers because they need
|knowledge
|about the internal structure of the TC header to display the values and
|parse
|the following address block. One of the great things of packetbb is that
|you
|can parse a message WITHOUT knowing anything about the semantic of the
|messages.
|
|But let's say we do it your way, and later we decide we need a new field
|in
|the header called <TC-Range>, which is two byte in length.
|
|The new header would look like
|   <TC-header> := <TC-flags>
|                  <TC-ANSN>
|                  <TC-Interval>?
|                  <TC-Validity>?
|                  <TC-Range>?
|
|Because the old parser don't know about the additional used bit in the
|<TC-flags> field and don't know about the length (or even existence) of
|the
|new <TC-Range> field, they cannot parse this message ! Some of the old
|parsers
|will even ignore the bit and mix up the <TC-Range> field with the
|beginning of
|an address block !
|
|> Comment on Ulrich his statement that IPv6 hellos are "long". There is
|no
|> reason for this, as packetBB can compress IPv6 to the same length as
|IPv4
|> IDs. It is a matter of addressing scheme. This area is my day to job
|(or
|> struggle..) in real world ad hoc networks. I may need IPv6 for good
|> reasons. And I definitely need efficient transport of data, also for
|good
|> reasons. My split mind: unique addresses by nature (random, EUI-64,
|etc.)
|> are great for reducing network management efforts, but at the same
|time the
|> addresses are hard to compress. This is one of the reasons I am
|working on
|> RouterIDs, msgs will be compact as long as the RouterIDs and delegated
|> prefixes can be compressed. This is doable.
|Sometimes you want RouterIDs, sometimes you don't want them because you
|run an
|simple autoconfiguration protocol. But 3-5 bytes is still very small
|compared
|to the whole OLSR message.
|
|> Please think again on the proposal. I know it is a small gain. But
|still:
|> it is gain. There is no disadvantage. Not at all !!
|Yes, there is...
|
|Henning
|
|*************************************************
|Diplom Informatiker Henning Rogge
|Forschungsgesellschaft für
|Angewandte Naturwissenschaften e. V. (FGAN)
|Neuenahrer Str. 20, 53343 Wachtberg, Germany
|Tel.: 0049 (0)228 9435-961
|Fax: 0049 (0)228 9435-685
|E-Mail: [email-masked]
|Web: www.fgan.de
|************************************************
|Sitz der Gesellschaft: Bonn
|Registergericht: Amtsgericht Bonn VR 2530
|Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.
|Joachim Ender (Stellv.)

---

From: Henning Rogge <[email-masked]>
Date: Thu, 23 Apr 2009 09:20:49 +0200

Am Thursday 23 April 2009 09:06:41 schrieb Teco Boot:
> Hi Henning,
>
> Currently, there is no standard for OLSRv2 and thus there is no compliant
> implementation. Backwards compatibility is no problem yet. It will be soon.
> All compliant NHDP and OLSRv2 implementations MUST be able to handle the
> suggested TC and H header. There is no "unknown" condition.
I'm talking about backward compatiblity AFTER we introduce the change.
Bitfields which control a header length cannot be extended without breaking 
backward compatiblity. So your proposal is a "dead end" which cannot be 
extended later, because extending the bitfield means earlier OLSR 
implementations will not be able to read the new header at all, so they have 
to skip the whole message.

> The TC-header and H-header are just TLVs. PacketBB readers do not have to
> know the internal structure of a TLV value. Not now and not in my proposal.
> "sub-parsing" the headers for packet header, message header and the
> suggested TC and H headers is very similar. This is what I mentioned
> already, the rules for adding new sub-fields would be "not allowed".
> Nothing new here.
A TLV with bitfields in the value to control it's content ? I still don't 
think this is a good idea.

We would also have to think about the Hello part of your proposal, because 
NHDP is used for more than OLSR, so it's a good idea to use a common namespace 
for common fields like a "validity/interval time".

Henning

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Apr 2009 09:45:07 +0200

Hi Ulrich,

Maybe you miss one point, TCs do repeat in packets.
My percentage are correct and applies for the savings of the fields that are
in scope.
Yes, it is a *small* gain. Still, *gain*.

Please describe a disadvantage that makes sense. I am still waiting.

Regards, Teco.

====

Van: [email-masked] [mailto:[email-masked]] Namens Ulrich Herberg
Verzonden: donderdag 23 april 2009 8:52
Aan: Teco Boot
CC: Thomas Heide Clausen; [email-masked]
Onderwerp: Re: [manet] Compressed TC and Hello message headers

Hi,

 

Please think again on the proposal. I know it is a small gain. But still: it
is gain. There is no disadvantage. Not at all !!

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Apr 2009 10:23:55 +0200

Hi Henning,

Inline.

|-----Oorspronkelijk bericht-----
|Van: Henning Rogge [mailto:[email-masked]]
|Verzonden: donderdag 23 april 2009 9:21
|Aan: Teco Boot
|CC: [email-masked]; 'Thomas Heide Clausen'; 'Ulrich Herberg'
|Onderwerp: Re: [manet] Compressed TC and Hello message headers
|
|Am Thursday 23 April 2009 09:06:41 schrieb Teco Boot:
|> Hi Henning,
|>
|> Currently, there is no standard for OLSRv2 and thus there is no
|compliant
|> implementation. Backwards compatibility is no problem yet. It will be
|soon.
|> All compliant NHDP and OLSRv2 implementations MUST be able to handle
|the
|> suggested TC and H header. There is no "unknown" condition.
|I'm talking about backward compatiblity AFTER we introduce the change.
|Bitfields which control a header length cannot be extended without
|breaking
|backward compatiblity. So your proposal is a "dead end" which cannot be
|extended later, because extending the bitfield means earlier OLSR
|implementations will not be able to read the new header at all, so they
|have
|to skip the whole message.

Yes, that is what I am saying also.

But it is not by definition. One may define a TLV with variable value length, with future expansion of sub-fields. For example, my Autoconf BRDP proposal makes use of ICMP ND RA options, called Border Router Information Option (BRIO). The BRIO has sub-options. Who knows one comes up with sub-sub options. One may suggest this for the TC or H header TLV. I did not !!

|> The TC-header and H-header are just TLVs. PacketBB readers do not have
|to
|> know the internal structure of a TLV value. Not now and not in my
|proposal.
|> "sub-parsing" the headers for packet header, message header and the
|> suggested TC and H headers is very similar. This is what I mentioned
|> already, the rules for adding new sub-fields would be "not allowed".
|> Nothing new here.
|A TLV with bitfields in the value to control it's content ? I still
|don't
|think this is a good idea.

It reduces overhead. That is all what I am saying.

|We would also have to think about the Hello part of your proposal,
|because
|NHDP is used for more than OLSR, so it's a good idea to use a common
|namespace
|for common fields like a "validity/interval time".

Not sure what you mean. 
For sure I agree we do not accept the proposal overnight. I hope you do not suggest OLSR (or others) maintain neighborhood state by itself, without NHDP? And even if one build such, what is the problem? I do not change functionality, it is just syntax.

Regards, Teco.

|Henning
|

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Apr 2009 09:50:06 +0100

> Please describe a disadvantage that makes sense.

That's already been done. But here's another - multi-value
interval and validity times as defined in RFC 5497.

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Apr 2009 09:58:47 +0100

> One may define a TLV with variable value length,
> with future expansion of sub-fields.

But then an "old" implementation that doesn't know
about the future expansion can't handle a "new"
message. While with the TLVs as defined, a new TLV
can be added and the "old" implementation can parse
it and ignore it. This is precisely the flexibility
that we built in to these specifications.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Apr 2009 12:02:10 +0200

Thanks. My suggestion does not support multi-value time values. This is a
disadvantage.
For hellos, it doesn't make sense to use multi-value times. For TCs, it
does.

In general, the concept using TLVs with value-blocks can be discussed. If
there are reasons using separate TLVs for each value element, that is OK. If
there are no reasons, I prefer efficiency.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Apr 2009 11:09:10 +0100

The over-riding reason for using TLVs, for motivating the
entire 5444 structure is flexibility againat the unknown,
creation of extensions and backward compatibility in the
way in which old implementations can know about new ones.
 
5444 is already a tradeoff of these various factors against
each other (as it discusses). We've been down the fixed
format route before, it's called OLSRv1. And OLSRv1 showed
itself as having problems in this area.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Teco Boot
Sent: 23 April 2009 11:02
To: Dearlove, Christopher (UK); 'Ulrich Herberg'
Cc: [email-masked]; 'Thomas Heide Clausen'
Subject: Re: [manet] Compressed TC and Hello message headers

                    *** WARNING ***

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

Thanks. My suggestion does not support multi-value time values. This is
a
disadvantage.
For hellos, it doesn't make sense to use multi-value times. For TCs, it
does.

In general, the concept using TLVs with value-blocks can be discussed.
If
there are reasons using separate TLVs for each value element, that is
OK. If
there are no reasons, I prefer efficiency.

Teco.