[OLSR-users] Bellman-Ford instead of Dijkstra?

[Sven-Ola Tuecke]

Thomas et al,

some notes from the more practical guiy:

- Current LQ is calculated on Hello-loss. Will be more accurate
  if changed to packet-loss.

- Bandwidth not considered: a link with 50% loss at 28mbit is
   better than a link with 25% at 1mbit (at least with real unicast
   applications beeing ACKed on the wifi level)

- Same for HNA. There is no qualified HNA (VDSL symmetric
  uplink should be preferred if compared to a modem uplink)

- Media change not considered: Routing through 2 disparate
  network interfaces on one device should be preferred, because
  this combi does not have the store-and-forward problem. Ex:

  [Ch10]==[Ch10]==[Ch10] is slower than
  [Ch10]==[Ch10/Ch01]==[Ch01] combined middle node.

  Xover can be assumed on Wifi/Ether & Wifi-Channelswitch

- Wifi/Mastermode repeats bcasts. To be punished by ETX-=0.5
   if more than one client. (netmask > 255.255.255.252)

- CPU load is the major limiter currently. Calculating an optimized
  path through a net uses to much of that. Radio / Streets / Social
  network: does not matter, this is a fundamental informatics problem
  encountered everywhere. Nodes-per-CPUspeed should be as high
  as possible.

Just a few cents of mine,
Sven-Ola

"Thomas Lopatic" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> Hey Benjamin,
>
> I thought through your idea again and - although you already explained
> it to me and I thought that I understood it - I am not quite sure any
> longer whether I really get it. Let me try to put it into my own words
> and see whether I understand what you're trying to accomplish.
>
> You're trying to establish two links between a node A and a node B. For
> this you have two interfaces per node, say A1 and A2 on node A as well
> as B1 and B2 on node B. Say, A1 talks to B1, A2 talks to B2.
>
> You would now like to use the A1/B1 link for packets from A to B. You
> would like to use the A2/B2 link for the opposite direction, i.e. for
> packets from B to A. In this way we would have a full-duplex connection
> between A and B, packets could flow in both directions at the same time.
>
> What this boils down to is an asymmetric scenario, doesn't it? From A's
> point of view, we want to leave the A1/B1 link at its original link
> quality and we want to make the A2/B2 link artificially bad, so that
> A1/B1 gets prefered when node A sends packets to B. On B, we'd like to
> make A1/B1 artificially bad and leave A2/B2, so that A2/B2 gets prefered
> when B sends packets to A.
>
> What this means is that A has another notion of the link quality of link
> A1/B1 and link A2/B2 than B. For A the former is good and the latter is
> bad, for B it's the other way around.
>
> Based on this, let me ask two questions that came to my mind when
> thinking through the scenario again.
>
> * We calculate our routing metric as follows: ETX = 1 / (NLQ x LQ). NLQ
> is the quality of a link as reported by our neighbour (e.g. 0.7 if the
> neighbour sees 70% of our packets), LQ is the quality of a link as
> measured by us. So, I am not sure whether we can use ETX with asymmetric
> routing as described above. The "LinkQualityMult" directive affects the
> link quality that we measure (and then report to our neighbourhood). So,
> if we use "LinkQualityMult" on a given link, then this link becomes
> better or worse for us and for our neighbours. There currently isn't any
> way to make us think that a link is good and at the same time our
> neighbours think that the same link is bad - which is the basis for the
> above asymmetric scenario, unless I am missing something here. Maybe the
> solution is to simply announce the modified link quality to our
> neighbours and ourselves use the original unmodified link quality. Hmm.
>
> * Why would the "LinkQualityMult" value have to be negative? Can't we
> stick to Dijkstra, i.e. isn't 0 "bad" enough a multiplier? Hmmm. Could
> you outline the scenario that you have in mind a little further?
>
> Hmmm. As I (mis)understand the whole thing now, it rather looks like an
> "asymmetric" kind of challenge and not that much a problem of negative
> weights, or?
>
> -Thomas
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users