Re: [B.A.T.M.A.N.] A few questions on TVLV

[Marek Lindner <mareklindner@neomailbox.ch>]

[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]

On Tuesday 22 October 2013 23:47:10 Linus Lüssing wrote:
> Or actually I just go ahead from the things which got mentioned in
> your email and on IRC by Antonio already.

The only reason I reply here is to give you pointers. I can only repeat what I 
wrote in the other mail: We need reasons why we need/want something instead of  
reasons why we could not not want something.


> # Code complexity
> 
> Wouldn't this actually reduce code complexity? Now the code needs
> to distinguish which packet type it got and based on that needs to
> perform TVLV parsing. "Moving TVLVs down to the common header"
> does not duplicating the code to for every packet type in my
> understanding, but the contrary, unifying things, "just moving" the
> current concept.

Please consider the broader picture: We need TVLV parsers everywhere. batctl 
and wireshark still can't not decode the TVLVs we have today. On top of that, 
TVLVs require dynamic header / memory management involving lists, locks, size 
calculations, etc which you simply don't have with static headers.


> # Network Traffic overhead
> 
> It's just 2 Bytes extra for the tvlv_len which doesn't seem much
> to me. Furthermore I'm wondering, whether saving these two bytes
> but not being able to run some new, more efficiant feature
> could be a net loss in terms of overhead in the future.

Please compare the original OGM size to the TVLV-OGM before starting to talk 
about '2 bytes extra' ...


> # TVLV parsing speed overhead
> 
> If no TVLV were actually added, then this would be nearly zero
> parsing overhead, checking whether tvlv_len == 0 is trivial. Of
> course, if no other packet types than the current TVLV capable
> ones were actually having TVLVs one day, then wouldn't need this
> discussion, true. Broadcast packets, for instance, aren't really
> on the fastest fastpath, thre it wouldn't harm TVLVs, I think. But
> also in general, I don't quite see, why packets on the fastpath
> shouldn't have some TVLVs in the future: For one thing the parsing
> speed overhead heavily depends on the kind of TVLV, how complex it
> is to parse it. And why not having some easy to parse TVLVs for
> those too? Embedded systems already need to be able to parse
> Ethernet and IP headers as well as IP options on a hop-by-hop
> basis in layer 3 routing. Also, even embedded systems become
> faster and faster every day.

So, you are saying there is overhead but we should not care because systems 
get faster and faster anyway ? Or are you saying your coming proposal only 
contains tvlv_len = 0 ?


> # Encapsulation speed overhead
> 
> Again, heavily depends on the kind of TVLV, doesn't it?

Your point being ? Actually, your last statement illustrates my point. Shortly 
after the start of the discussion we are already so abstract that I don't even 
know what we are talking about.

Cheers,
Marek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]