Re: [manet] packetbb update idea

["Dearlove, Christopher (UK)" <[e-mail]>]

Unfortunately, you can’t build a TLV-unaware optimum 5444 message constructor, because of different unspecified values. Using the UNSPECIFIED value introduced in 5198 can significantly improve efficiency, but the real winner (for OLSRv2 at least) is the (different) equivalent for LINK_METRIC. (Or, you can manage without the latter and then UNSPECIFIED becomes the winner.)

It’s not ideal, but it’s got less impact on other people (note that phrase) than modifying 5444.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: Justin Dean [mailto:[e-mail]]
Sent: 06 July 2017 17:31
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [e-mail]
Subject: Re: [manet] packetbb update idea


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.


On Thu, Jul 6, 2017 at 5:28 AM, Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:
Just to nail this one down.

Justin:
> I don't see how having a bit field would work as the order of the addresses in the address block are not guaranteed to be in any specific order.

As I indicated, that’s not a problem. We don’t assign meaning to positions, but we can use positions. As we do every time an Address Block TLV has an index or two indices.

So considering

A-----B
|    /|
|   / |
|  /  |
| /   |
|/    |
C-----D

Let’s assume the addresses are in order A, B, C, D. (If they change, we change TLV values. Which we potentially have to do any time the order changes anyway.)

Changing the value of a TLV based on the order of the addresses in the addresss block seems CRAZY to me.  The way my code is organized is that TLVs are assigned to addresses and then all addresses with associated TLVs are given to the packetbb "compiler" that builds the RFC5444 packet in the most efficient way it can, address compression, TLV groupings, multi indexed, all indexed, etc.  That bit of code doesn't know anything about the values of the TLVs other than that they are associated with the address.  The reverse is also an issue in that the bit of code that cares about TLV values doesn't care at all what index the address is.  To say that order doesn't matter and we can't enforce order (like we argued against in assigning meaning to addresses with AODVv2) and then say that order can matter in this case because we could just assign a TLV value after the order is assigned seems arbitrary to me.

The bit field would work but it gets much less efficient when there are values you want to include in the association.  One could append them at the end of the TLV bit field but that doesn't really work as the TLV size would me messed up.  The efficiency is only there when there are boolean associations.

I could be into the idea of an indirect that RFC5444 would be aware of and provide those associations to the protocols.  I thought about that first as it has the advantages that a single extra address doesn't (like larger than pairwise associations and random) but stopped as it would be horribly complex to shoehorn it in and the single address would be sufficient for 90%.

You mentioned you had a bunch of ideas on how you might improve the format.  I'd love to hear some of them.
********************************************************************
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.
********************************************************************