Re: [manet] packetbb update idea

[Justin Dean <[e-mail]>]

On Thu, Jul 6, 2017 at 5:28 AM, Dearlove, Christopher (UK) <
[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.