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

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

[Linus Lüssing]

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

Hi,

I think I had posted some thoughts on the TVLV feature on the IRC
channel before with some suggestions for changes (e.g. moving the
TVLV feature from the individual packet types down to the common
batman header). And had tried to come up with examples for
features where TVLVs for batman broadcast packets could be useful
- which might have been potential, but not the most convincing,
not the most awesome features.

So now I have a feature which I would like to have / would like to
work on in the future [0], and I would like to know:

a) Whether it is possible to do that with the current TVLV
infrastructure without breaking compatibility.

I think it is, probably by announcing this capability via an OGM
TVLV and only activating this feature if all visible nodes support
it, right?

b) If it is possible without breaking compatibility, then this
could still cause quite some burdon for heterogeneous, multi party
controlled networks, because all nodes would need to
upgraded or older ones somehow blacklisted, right?

c) What is your estimation, would it be easy to pull the TVLV
feature down onto the common batman-header code-wise?

d) Would the ease or difficulty to implement it (c)) and the
benefits it would provide (a)+b)) justify including a patch
for a TVLV-per-batman-header in the first compat bump release?

e) The first compat bump patches were already submitted to net/,
so there actually wouldn't be much time left to do that, would
there?

Cheers, Linus

PS: I would also volunteer to work on moving the TVLV down to the
common batman header, but if the time frame to do that is too
short then I'd probably not be fast enough to do that.


[0]: Split Horizon with a tag (the tag would need a per batman bcast TVLV)
* A per hard-interface mechanism tries to automatically detect whether
  the connectivity to all local link layer neighbors is both
  transitive and symmetric.
* If so broadcast/multicast packets coming from that interface are
  tagged with a unique ID (e.g. the lowest MAC address present on
  that link)
* Such tagged packets are never forwarded onto the according link
  again.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Marek Lindner]

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

On Sunday 20 October 2013 10:25:07 Linus Lüssing wrote:
> I think I had posted some thoughts on the TVLV feature on the IRC
> channel before with some suggestions for changes (e.g. moving the
> TVLV feature from the individual packet types down to the common
> batman header). And had tried to come up with examples for
> features where TVLVs for batman broadcast packets could be useful
> - which might have been potential, but not the most convincing,
> not the most awesome features.
> 
> So now I have a feature which I would like to have / would like to
> work on in the future [0], and I would like to know:

Before we discuss how we get TVLVs 'down to the common batman header' we 
should talk about why that would be useful. What are the advantages and 
disadvantages ? Adding tvlvs everywhere for the mere sake of having them 
around isn't good enough as they increase code complexity, network traffic 
overhead and encapsulation speed penalties.

Cheers,
Marek

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

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

[Linus Lüssing]

On Sun, Oct 20, 2013 at 06:26:41PM +0800, Marek Lindner wrote:
> On Sunday 20 October 2013 10:25:07 Linus Lüssing wrote:
> > I think I had posted some thoughts on the TVLV feature on the IRC
> > channel before with some suggestions for changes (e.g. moving the
> > TVLV feature from the individual packet types down to the common
> > batman header). And had tried to come up with examples for
> > features where TVLVs for batman broadcast packets could be useful
> > - which might have been potential, but not the most convincing,
> > not the most awesome features.
> > 
> > So now I have a feature which I would like to have / would like to
> > work on in the future [0], and I would like to know:
> 
> Before we discuss how we get TVLVs 'down to the common batman header' we 
> should talk about why that would be useful. What are the advantages and 
> disadvantages ? Adding tvlvs everywhere for the mere sake of having them 
> around isn't good enough as they increase code complexity, network traffic 
> overhead and encapsulation speed penalties.
> 
> Cheers,
> Marek

Agreed, bloated, never used code is never a good thing. And yes,
before we do get into discussing the specific proposal, we should
discuss the current limitations, (perceived) issues.

To be honest, I'm not 100% sure about the advantages and
disadvantages, that's why I had decided to ask questions,
initially :).


This is my current (probably wrong) understanding about the
disadvantages of the current implementation:

With the current TVLV approach it is still going to be difficult
to introduce new features / changes to batman-adv broadcast /
coded / fragment / ... packets as the current approach only
provides TVLVs for OGMs and unicast packets.

How difficult, I'm not quite sure. Initially I thought compat
bumps would be needed for new broadcast features for instance,
but now I realized, that this is not the case, because bcast features
could be signalized via OGM TVLVs and like with the mcast patches,
could be enabled only if all nodes have that bcast-feature OGM
TVLV.

So I guess the only disadvantage is, that you would either only be
able to use a new bcast feature, if all nodes had it (which might
be painful in a heterogeneous mesh network). Or if it is an
optimization which can be applied "locally", then the according
nodes would need to convert the broadcast packets back and forth.


So vice versa, the advantage of having TVLVs for broadcast packets
would be to have ignorable features, no need for conversions
because the TVLV could be skipped, no compat bumps, not always a
need to wait for all nodes to be upgraded to make the feature effective
- just like for the current OGM and unicast TVLVs. We'd have the
same flexibility provided by a uniform framework for all packet
types from an "infrastructure point of view".

--

For the disadvantages of moving 'TVLVs down to the common header',
I'm actually having trouble getting them. Maybe others could list
them again and I try to explain which of these I'm having trouble
understanding and why?

Cheers, Linus

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

[Linus Lüssing]

On Tue, Oct 22, 2013 at 11:26:04PM +0200, Linus Lüssing wrote:
> On Sun, Oct 20, 2013 at 06:26:41PM +0800, Marek Lindner wrote:
> > On Sunday 20 October 2013 10:25:07 Linus Lüssing wrote:
> > > I think I had posted some thoughts on the TVLV feature on the IRC
> > > channel before with some suggestions for changes (e.g. moving the
> > > TVLV feature from the individual packet types down to the common
> > > batman header). And had tried to come up with examples for
> > > features where TVLVs for batman broadcast packets could be useful
> > > - which might have been potential, but not the most convincing,
> > > not the most awesome features.
> > > 
> > > So now I have a feature which I would like to have / would like to
> > > work on in the future [0], and I would like to know:
> > 
> > Before we discuss how we get TVLVs 'down to the common batman header' we 
> > should talk about why that would be useful. What are the advantages and 
> > disadvantages ? Adding tvlvs everywhere for the mere sake of having them 
> > around isn't good enough as they increase code complexity, network traffic 
> > overhead and encapsulation speed penalties.
> > 
> > Cheers,
> > Marek
> 
> Agreed, bloated, never used code is never a good thing. And yes,
> before we do get into discussing the specific proposal, we should
> discuss the current limitations, (perceived) issues.
> 
> To be honest, I'm not 100% sure about the advantages and
> disadvantages, that's why I had decided to ask questions,
> initially :).
> 
> 
> This is my current (probably wrong) understanding about the
> disadvantages of the current implementation:
> 
> With the current TVLV approach it is still going to be difficult
> to introduce new features / changes to batman-adv broadcast /
> coded / fragment / ... packets as the current approach only
> provides TVLVs for OGMs and unicast packets.
> 
> How difficult, I'm not quite sure. Initially I thought compat
> bumps would be needed for new broadcast features for instance,
> but now I realized, that this is not the case, because bcast features
> could be signalized via OGM TVLVs and like with the mcast patches,
> could be enabled only if all nodes have that bcast-feature OGM
> TVLV.
> 
> So I guess the only disadvantage is, that you would either only be
> able to use a new bcast feature, if all nodes had it (which might
> be painful in a heterogeneous mesh network). Or if it is an
> optimization which can be applied "locally", then the according
> nodes would need to convert the broadcast packets back and forth.
> 
> 
> So vice versa, the advantage of having TVLVs for broadcast packets
> would be to have ignorable features, no need for conversions
> because the TVLV could be skipped, no compat bumps, not always a
> need to wait for all nodes to be upgraded to make the feature effective
> - just like for the current OGM and unicast TVLVs. We'd have the
> same flexibility provided by a uniform framework for all packet
> types from an "infrastructure point of view".
> 
> --
> 
> For the disadvantages of moving 'TVLVs down to the common header',
> I'm actually having trouble getting them. Maybe others could list
> them again and I try to explain which of these I'm having trouble
> understanding and why?

Or actually I just go ahead from the things which got mentioned in
your email and on IRC by Antonio already.

# 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.

# 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.

# 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.

# Encapsulation speed overhead

Again, heavily depends on the kind of TVLV, doesn't it?


Cheers, Linus

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

[Marek Lindner]

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

On Tuesday 22 October 2013 23:26:05 Linus Lüssing wrote:
> With the current TVLV approach it is still going to be difficult
> to introduce new features / changes to batman-adv broadcast /
> coded / fragment / ... packets as the current approach only
> provides TVLVs for OGMs and unicast packets.

What kind of features are missing ? Can we please stay specific and not drift 
into the "meta" future where everything and anything could be added ? What is 
the feature or the features we are talking about ?


> How difficult, I'm not quite sure. Initially I thought compat
> bumps would be needed for new broadcast features for instance,
> but now I realized, that this is not the case, because bcast features
> could be signalized via OGM TVLVs and like with the mcast patches,
> could be enabled only if all nodes have that bcast-feature OGM
> TVLV.

Currently, I could not come up with a bcast feature we would want to add that 
requires a compat bump. Please name it/them and state why a compat bump would 
be needed. This is where the discussion can start.


> For the disadvantages of moving 'TVLVs down to the common header',
> I'm actually having trouble getting them. Maybe others could list
> them again and I try to explain which of these I'm having trouble
> understanding and why?

Again, let's start with an advantage of adding TVLVs using a practical 
example. We don't want to implement TVLVs for the sake of implementing TVLVs.

Cheers,
Marek

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

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

[Marek Lindner]

[-- 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 --]