Subject: [manet] [OLSRv2] Variable validity times for TC addresses

From: "Rogge Henning" <[email-masked]>
Date: Wed, 2 Feb 2011 12:47:01 +0100

Hi,

We are planning our OLSR.org OLSRv2 implementation at the moment. While
discussing some details of the necessary datastructures of the OLSRv2 draft,
we noticed something interesting.

The datastructures in the OLSRv2 draft are designed to store a single
validity time for each stored node-edge or node-attached_network pair, it
does not store the validity time per node.

I think we could exploit this fact in OLSRv2.

I propose we allow the usage of a VTIME TLV for the addresses inside a TC
message to overwrite the validity times defined in the message TLV for a
address.

An usecase for this would be attached network entries in TCs. In many cases
this attached networks are hardwired to the OLSR router, so their status
should stay static for long times. By applying them a longer VTime we could
safe space in the rest of the TCs (where we don't need to mention the
attached network) without needing to send the attached network addresses in
their own message fragment.

Another usecase would be to allow a local link metric algorithm to estimate
the agility of links and set custom validity times for each of them. This
could be a way to reduce the network traffic in highly heterogeneous
networks.

The second usecase might require that OLSRv2 allow the usage of VTIME-TLVs
in OLSRv2 Hello messages, so that the validity time can be copied into the
TCs of their neighbors.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für 
Kommunikation, Informationsverarbeitung und Ergonomie FKIE 
Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg, 
Germany Telefon +49 228 9435-961,   Fax +49 228 9435 685 
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Feb 2011 12:37:38 -0000

We have considered allowing individual validity times, but
there are some quite unpleasant consequences as I recall,
but right now not the details. Note that NHDP is already
published without such a capability, and NHDP supplies
some of the links you are using.

I'm not sure what "does not store the validity time per
node" means. AR_time essentially does that job.

However attached networks are, as you say, an interesting
case, and the NHDP objection above doesn't apply to them,
nor I think does whatever other issues there may be. That
case may be worth further consideration - although right
now more complications isn't high on my wish list. But
the link metrics case I don't like, as those are going
in HELLO messages, and teh NHDP objection applies in
force.

I also think there is a danger, even with the attached network
case, of pushing further back an already overdue protocol.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rogge Henning
Sent: 02 February 2011 11:47
To: [email-masked]
Subject: [manet] [OLSRv2] Variable validity times for TC addresses

Hi,

Henning Rogge

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Rogge Henning" <[email-masked]>
Date: Wed, 2 Feb 2011 14:16:31 +0100

> -----Ursprüngliche Nachricht-----
> Von: Dearlove, Christopher (UK) 
> 
> there are some quite unpleasant consequences as I recall, but 
> right now not the details. Note that NHDP is already 
> published without such a capability, and NHDP supplies some 
> of the links you are using.
> 
> I'm not sure what "does not store the validity time per node" 
> means. AR_time essentially does that job.
You mean AN_time ?

As I read the section 9.4 of the draft, there is one AN_time value stored
for each tuple with a single attached network in it.

So we might have tuples like this (originator, prefix, distance, sequence
number, vtime):

(192.168.0.1, 10.0.0.0/16, x, y, 100 seconds)
(192.168.0.1, 10.1.0.0/16, x, y,  50 seconds)

> case, and the NHDP objection above doesn't apply to them, nor 
> I think does whatever other issues there may be. That case 
> may be worth further consideration - although right now more 
> complications isn't high on my wish list.

> But the link 
> metrics case I don't like, as those are going in HELLO 
> messages, and teh NHDP objection applies in force.
I am not completely sure it has to be included into the HELLOs (does OLSRv2
handle asymmetric validity times for a link well ?).

And OLSRv2 already adds TLVs to the Hellos, so as long as they don't
conflict with the working of NHDP, adding another TLV to help the other node
with creating TCs might be okay. And as long as a node only decrease the
validity time of a link (compared to the value from the Hello), it might
work well.

But the "attached network case" is definitely an easier target.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Feb 2011 13:46:23 -0000

I meant AR_time, as I said, which records the validity time of the
node the network is attached to. TC message sending nodes only.

I recall one of the issues with reducing a validity time in a
message, let's consider a HELLO message for example. Default
parameters, period 2 seconds (jittered, but we can ignore that
for now), validity 6 seconds. If you put something in with a
validity  seconds (say) you are a lot less robust against
message loss. If you put something in with a validity time
of 1 second you are going to lose it before your next HELLO
message. So now you have to reduce your HELLO interval to
(say) 1/3 second. But now you could reduce other validity times
as the longer time isn't actually winning you anything (we'll
assume losing more than two in three messages is too bad to
use anyway).

So the net effect is that having a variable validity time
doesn't help, except marginally in message size with a
significantly greater complexity in the distinction between
REFRESH_INTERVAL and HELLO_INTERVAL and partial messages.
And for TC messags we don't have even that currently.

I will note that the attached message case suffers from a
related issue. Let's suppose we are sending TC messages at
5 second intervals, and you want to set an attached message's
validity time to 1 hour rather than 15 seconds. What's that
winning you? Nothing, if you report that attached network in
every TC message. OK, you could (with suitable redefinitions,
that one would have to get right) omit it from most TC
messages. But now you've lost the capability for a new node
to join the network and get quickly (small multiple of 5
seconds worst case) updated to complete network knowledge.
Yes, you could now make reportng the network responsive
(if a new node turns up in your routing table, make one or
more of your next TC messages include attached networks).
More complications - and for links rather than attached
networks doesn't work (potential chicken and egg problem
you may not see the new node without links).

So I think it's a significant additional complication for
a very limited win.

-----Original Message-----
From: Rogge Henning [mailto:[email-masked]] 
Sent: 02 February 2011 13:17
To: Dearlove, Christopher (UK); [email-masked]
Subject: AW: [manet] [OLSRv2] Variable validity times for TC addresses

You mean AN_time ?

Henning Rogge

---

From: "Rogge Henning" <[email-masked]>
Date: Wed, 2 Feb 2011 15:23:36 +0100

> I meant AR_time, as I said, which records the validity time 
> of the node the network is attached to. TC message sending nodes only.
Okay, but why is this a problem ? If the node vanishes from the net, it can
still take its HNAs with it. 
 
> parameters, period 2 seconds (jittered, but we can ignore 
> that for now), validity 6 seconds. If you put something in 
> with a validity  seconds (say) you are a lot less robust 
> against message loss. If you put something in with a validity 
> time of 1 second you are going to lose it before your next 
> HELLO message. So now you have to reduce your HELLO interval to
> (say) 1/3 second. But now you could reduce other validity 
> times as the longer time isn't actually winning you anything 
> (we'll assume losing more than two in three messages is too 
> bad to use anyway).
Consider other timings with higher differences between validity time and
interval time.

A typical freifunk/funkfeuer network (as an example) use HELLO timings of
2/20 seconds or even 5/100 seconds.

If you have a validity time of 100 seconds, there is lots of space to choose
your intervals and "reduced" intervals from.

Considering a link broken just because two of three HELLOs are missing will
not work that well on many networks. Even with 10% multicast packet loss
(which will be less than 1% unicast packet loss for WLAN) you will get a
link drop (on average) every 40 minutes (with one HELLO every 2 seconds).

> winning you? 
Typical VTime for our networks is hundreds of seconds because we have
(mostly) stationary nodes. It would make sense to lessen the VTime of links
to (or between) mobile nodes to a much smaller value while keeping the long
VTime for the stationary nodes.

> Nothing, if you report that attached network in 
If you increase the interval between updates of static links from 5 to 60
seconds for static/stable links (as an example) you still have a pretty good
working network while you can skip the IPs from 11 out of 12 TCs.

> So I think it's a significant additional complication for a 
> very limited win.
I don't think it will make implementing the protocol according to the
Draft/RFC much more difficult, but it allows us for increased flexibility
which can be useful in my oppinion.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Feb 2011 14:41:02 -0000

> still take its HNAs with it.

I was replying to you saying there was a problem, or
to be more precise that there weren't any node times.
I didn't suggest there was a problem.
 
> 2/20 seconds or even 5/100 seconds.

Unimportant. all that matters is ratios, not absolute values. (Well,
until
we get down to very small values, but we're not talking about that
here.)

> your intervals and "reduced" intervals from.

No, same comment.

> not work that well on many networks.

So you up the ratio from x3 to x5 or whatever you want. Again, not the
critical issue.

> VTime for the stationary nodes.

This is missing the point. Either you repeat the information in all
HELLO messages, so longer times don't help, or you don't repeat the
information, with a small overhead saving, increased complexity and
reduced ability for new nodes to join the network (or increased
complexity in an additional way to create TC messages responsive
to adding routes in the routing table).

> Draft/RFC much more difficult

I think you are mistaken there.

> but it allows us for increased flexibility which can be useful in my
oppinion.

And I think you are mistaken there too, unless running a
system where responsiveness of new nodes isn't important.

I'm going to apologise in advance now for not being able to
contine this discussion right now, other things to do.