[B.A.T.M.A.N.] Improving the roaming procedure: multiple roaming within one orig interval

[B.A.T.M.A.N.] Improving the roaming procedure: multiple roaming within one orig interval

[Antonio Quartulli]

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

Hello people,

as some of you may know, batman-adv has client fast-roaming support since
version 2011.3.0. This technique has been introduced together with the new
client announcement mechanism and it is described on its wikipage[0].

At the bottom of the same it is also written that multiple roaming of the same
client within one originator interval are not supported.

Right now I am working on a concept that would enable such possibility. I tried
to summarise my ideas on the wiki as well[1] in order to share with you the
solution I am thinking about.

The document is still a draft and may not be 100% understandable. If you have
time and you are curious enough to read the wiki, please drop me your feedback,
it would really be appreciated :-)

Thank you,

[0] http://www.open-mesh.org/wiki/batman-adv/Client-roaming
[1] http://www.open-mesh.org/wiki/batman-adv/MultipleRoaming

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

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

Re: [B.A.T.M.A.N.] Improving the roaming procedure: multiple roaming within one orig interval

[Marek Lindner]

Hi,

> Right now I am working on a concept that would enable such possibility. I
> tried to summarise my ideas on the wiki as well[1] in order to share with
> you the solution I am thinking about.
> 
> The document is still a draft and may not be 100% understandable. If you
> have time and you are curious enough to read the wiki, please drop me your
> feedback, it would really be appreciated :-)

if I understand the document correctly each mesh node a client connects to 
will send a roaming advertisement back to the last known mesh node this client 
was connected to. A few questions come to my mind:

 * Does this already work with the current code ? If not what happens now ?
 * How do all nodes get back in sync ? It sounds to me like for certain while 
a number of nodes claim the same client, right ? Nobody tells the intermediate 
mesh nodes that their client has moved.
 * What if receiving a roaming advertisement triggered an immediate 
(unscheduled) OGM broadcast ? That would potentially speed up the gap and also 
address the "longer path" problem you outlined in the wikipage.

Regards,
Marek

Re: [B.A.T.M.A.N.] Improving the roaming procedure: multiple roaming within one orig interval

[Antonio Quartulli]

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

On Thu, May 10, 2012 at 09:12:37 +0800, Marek Lindner wrote:
> 
> Hi,
> 
> > Right now I am working on a concept that would enable such possibility. I
> > tried to summarise my ideas on the wiki as well[1] in order to share with
> > you the solution I am thinking about.
> > 
> > The document is still a draft and may not be 100% understandable. If you
> > have time and you are curious enough to read the wiki, please drop me your
> > feedback, it would really be appreciated :-)
> 
> if I understand the document correctly each mesh node a client connects to 
> will send a roaming advertisement back to the last known mesh node this client 
> was connected to.

Yes, this is the idea.

> A few questions come to my mind:
> 
>  * Does this already work with the current code ? If not what happens now ?

Now the ROAM_ADV is still sent to the last known mesh node the client was
connected to, but the rerouting mechanism could be broken by other nodes that
still think the client is connected to them. (if a client at A roams to B and
then to C, B could break the rerouting).

>  * How do all nodes get back in sync ? It sounds to me like for certain while 
> a number of nodes claim the same client, right ? Nobody tells the intermediate 
> mesh nodes that their client has moved.

all the nodes will advertise the entry and so all the nodes will delete it,
but, eventually, the node that is really serving the client will re-add it and
advertise it again.
Yap, this must be improved. thank you for pointing it out.

>  * What if receiving a roaming advertisement triggered an immediate 
> (unscheduled) OGM broadcast ? That would potentially speed up the gap and also 
> address the "longer path" problem you outlined in the wikipage.

I have to think about that... Imho the OGM should not be the solution, because an
OGM have a not negligible prob to be lost. So we should not rely on it.


Thank you for your comments!
I'll try to refine the concept a bit more to address the problem you pointed
out and then I will post an update here :-)

Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

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