public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <ordex@autistici.org>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCHv2] batman-adv: forward late OGMs from best next hop
Date: Sat, 25 May 2013 23:42:19 +0200	[thread overview]
Message-ID: <20130525214219.GK1679@ritirata.org> (raw)
In-Reply-To: <20130525210748.GA11731@Linus-Debian>

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

On Sat, May 25, 2013 at 11:07:48PM +0200, Linus Lüssing wrote:
> Hi Simon,
> 
> I'm currently wondering whether changing the protocol in the way
> you described is sufficient.
> 
> I think it still has the problem of not converging to the optimal
> solution in various scenarios, for instance:
> 
> ----------
> 
>     B1 ---------
>   /             \        
> A        C1 ---- D
>   \    /        /
>     B2 - C2 ----
> 
> A-B1:   10%, 0ms
> A-B2:  100%, 0ms
> B2-C1:   5%, 0ms
> B2-C2: 100%, 5ms
> B1-D:  100%, 0ms
> C1-D:  100%, 0ms
> C2-D:  100%, 0ms
> ('link': 'link-quality', 'link-delay')
> 
> Obviously, here the path A-B2-C2 is the best, having a 100% link
> quality. However with this patch, it will select A-B1-D, having
> only a 10% link quality (I'm not considering asym/hop-penalty or
> that 0ms delay is unrealistic, and I'm not considering that the
> link quality will cause lost OGMs - just to keep things simple):
> 
> 
> The OGM from D gets forwarded to B1 and then to A instantly; A
> notes a path quality of 10% towards D via B1.
> 
> The OGM from D reaches B2 via C1 first, so B2 first forwards an
> OGM with a path quality of 5% to A first. A notes a path quality
> of 5% towards D via B2.
> 
> Then the OGM from D reaches B2 via C2, too. Now, with this patch
> B2 will correctly choose the path via C2, B2 notes a 100% path
> quality towards D via C2 instead of ignoring this OGM.

This was true also before this patch.

> And B2 will
> also rebroadcast this OGM.
> 
> However, A will ignore this second OGM from D via B2 because it
> came from the same neighbor even though it came from the best,
> optimal, 100% link-quality path.
> 
> ----------
> 
> While converging to a path after applying this patch is obviously
> better than the starvation which can currently happen I'm
> still wondering whether the issue could be solved better.
> 
> What if we were always rebroadcasting/forwarding an OGM even from
> the same neighbor, too, if the sequence number is the same but the
> TQ better (so similar to what is specified for BATMAN V)?

If I am not wrong this is what is going to happen, but with one originator
interval of delay.

If I correctly got your example, this happens the first time only, but from the
next originator interval B2 will only rebroadcast the OGM coming from C2 since
this is the best next hop for it. So yes, this can happen but only the first
time. As soon as B2 learns the best route via C2.

What this patch is changing is to make B2 rebroadcast the OGM coming from C2
(best next hop) in case the latter arrived after the OGM coming from C1 (which
is not rebroadcasted because C1 is not best next hop). Actually the fix is only
acting on the duplicate detection only (which affect forwarding).

So, without this patch, in this case I described, we were having a real "block".
There is no change in the route selection. The routes are still selected the
same way as before.


Cheers,


-- 
Antonio Quartulli

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

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

  reply	other threads:[~2013-05-25 21:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-23 11:07 [B.A.T.M.A.N.] [PATCHv2] batman-adv: forward late OGMs from best next hop Simon Wunderlich
2013-05-23 11:17 ` Antonio Quartulli
2013-05-25 21:07 ` Linus Lüssing
2013-05-25 21:42   ` Antonio Quartulli [this message]
2013-05-26 15:14     ` Simon Wunderlich
2013-05-26 20:23       ` Antonio Quartulli
2013-06-09  4:30 ` Marek Lindner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130525214219.GK1679@ritirata.org \
    --to=ordex@autistici.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox