Re: [manet] packetbb update idea

Your point on wanting to create a protocol that it's needed for is valid.
I'm not wanting to shove this through;  I'd just like some
positive/constructive debate on list.

On Thu, Jul 6, 2017, 12:50 PM Christopher Dearlove <
christopher.dearlove@gmail.com> wrote:

> No, I'm not going to describe my ideas for improvement because they miss
> the point that the gains are minor, everything can be done in another way,
> and the costs are serious - every implementation out there has to either
> change or no longer guarantee backward compatibility. And the cases of mine
> and yours are a step or more away from a real use case. By which I mean "we
> could carry this sort of data" is not a use case of value. I want to create
> a protocol to do this for this reason might be. (I want to solve this
> problem is even better.)
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com
> chris@mnemosyne.demon.co.uk is dead
>
> On 6 Jul 2017, at 17:31, Justin Dean <bebemaster@gmail.com> wrote:
>
>
>
> On Thu, Jul 6, 2017 at 5:28 AM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> 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.
>
> _______________________________________________
>
>
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>