[aodvv2-discuss] Re: Packet sketches and some RFC5444 info by Henning
- From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Mon, 29 Dec 2014 19:12:52 +0100
Hi all,
I'd like to talk about RFC5444 messages again. If you don't have time (or just
don't want to) to respond over the holidays, I totally understand, but I
thought I'd just start the conversation.
While working on my packet_sketch branch, it began to dawn on me that I'm
actually trying to change two things at once: the *what* and the *how*. I'm
afraid that discussing my changes may get very confusing if I continue like
that, so I'd like to pin down the what before (or while) I work on the how.
What i exactly mean by these terms is:
the what: Even after working with the AODVv2 draft for quite some time now, I
don't think that I can confidently say that I understand the structure of the
RFC5444 messages it described, especially since it turned out in honolulu that
the things I thought I had worked out and gotten the OK from Charlie for ere
actually false. Right now, I'm just sort of describing the message structure
that *I* think is a good idea (and that I actually implemented) in my proposed
changes. I'd like to check back with you if you agree with my proposal as soon
as possible.
the how: How the messages are actually described (i.e. do we have more tables,
which text do we put where, what do the graphics i our appendix look like..
etc.)
Now, concerning the what: I've tried to write down my Idea of AODVv2 RFC5444
messages in the packet_sketch.md file of the packet_sketch branch (the content
of which I've copied to
https://gist.github.com/Lotterleben/b500a2a4823bd18738f8, in case John wants to
take a look at it while he's not a work). I knowingly deviated from the draft's
instructions on two points:
- there is no Metric Type TLV. Instead, I've used an extension type to the
metric TLV to specify the metric type
- I pretty much ignored anything concerning prefix lengths because I didn't
need them for my use case and I didn't want to do anything wrong
I have no idea if the rest of it conforms with the draft's ideas.
I'd be very grateful if you could tell me if this message format makes sense,
and if it is what you had in mind, or what should be changed, etc. Once we are
in agreement about that, rewriting the message description itself will involve
significantly less ifs and buts.
Cheers,
Lotte
(unfortunately, Thomas hasn't answered me yet, so there's no news concerning
the RFC5444 best practices.)
Am 18.12.2014 um 21:05 schrieb Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>:
> Hi Charlie,
>
> Am 18.12.2014 um 16:31 schrieb Charlie Perkins
> <charles.perkins@xxxxxxxxxxxxx>:
>
>>
>> Hello Lotte,
>>
>> I did receive this email.
>>
>
> Yay, thanks for the clarification! (also, thank you for uploading the -05.xml)
>
>> I am hoping you will not object if I post Justin's issues today.
>>
>> As noted in the file I pushed to Github, there are some other
>> old issues that need to be also posted to the issue tracker, but
>> I think they are already resolved also.
>>
>> Regarding packet-size versus "parsing time", it's useful to remember
>> that transmitting one bit consumes somewhere between 10,000
>> and 10,000,000 times as much energy as one processor instruction.
>>
>
> I am aware of that, but I don't see that this is an argument against
> RFC5444's flexibility. We can have it all ;)
>
>> I'll take a look at packet_sketch.md later today, but first I need
>> to gather the rest of the text for the issues.
>> Did anyone here
>> look at the files I uploaded?
>
> I have, but I'm not quite sure how to work with it. Intuitively, I would've
> expected it to have a “resolved by” column or something... Maybe we can add a
> brief intro to the spreadsheet to our agenda for friday?
>
> Cheers,
> Lotte
>
>>
>> Regards,
>> Charlie P.
>>
>> On 11/24/2014 10:16 AM, Lotte Steenbrink wrote:
>>> Hi All,
>>> I just had the chance to ask Henning some more questions about his oonf api
>>> and RFC5444 in general. He confirmed to me what we had discussed earlier in
>>> Honolulu: that really, all AODVv2 should be specifying is the *what*, but
>>> not the *how*.
>>> In detail:
>>>
>>> - The “tools” RFC5444 gives us are Message and Packet Headers, Addresses,
>>> TLVs associated with an Address, and TLVs that belong into the Message
>>> Body. That's it. What you tell the parser is the relationship between you
>>> message data, and the RFC5444 generator figures out the rest. Some
>>> generator may be optimized for minimum packet size and squeeze out every
>>> bit they can by using multivalue TLVs and all kinds of optimization bells
>>> and whistles. Some may be optimized for quick and easy parsing and go for a
>>> very clear, but rather byte-consuming structure. Because RFC parsers are
>>> required to understand all of these representations and translate them back
>>> to the “relationship between data” that they were fed, it shouldn't matter
>>> to the protocol at all. This means two things:
>>> * We don't have to bother with thassingleindex flags and the like. This
>>> is all up to the RFC5444 generator
>>> * We don't have to throw minimum packet size out of the window, as
>>> Charlie worried on multiple occasions. Implementations for constrained
>>> networks can simply use a RFC5444 generator (or build their own) which is
>>> optimized to build tiny packets.
>>>
>>> - Because I used extension types to build my messages (see below/github), I
>>> wanted to make sure I didn't misuse them. He confirmed that extension types
>>> are used for TLVs that follow some kind of “Theme”, and that having a TLV
>>> Type for the Metric value and then using extension types to specify the
>>> metric being used (for example, hop count) makes sense. He also explained
>>> to me that the default extension type is 0. Extension types with the value
>>> 0 do not have to be stated explicitly (i.e. a missing extension type is
>>> equal to an extension type of value 0), thus saving 8 bits per TLV (of
>>> course, the generator may optimize packet sizes by accumulating several
>>> TLVs in one multi-value TLV, so saving (8 * number_of_tlvs) bytes ist
>>> actually the “worst case”). So it makes sense to use 0 for extension types
>>> which denominate default values. ;)
>>>
>>> I'm sure none of this is news to you, but since there have been
>>> miscommunications about these things before, I thought I should rather be
>>> on the verbose side.
>>> Based on the above information, I've eliminiated most TODOs in my packet
>>> sketch and added some details. You can find it in the packet_sketch.md file
>>> on the packet_sketch branch on github.
>>>
>>> Maybe this is helpful.
>>> Cheers,
>>> Lotte
>>>
>
Other related posts:
