> On 13.12.2016, at 3.27, David Schinazi <dschin...@apple.com> wrote:
..
> and was thinking that we might be able to make this even simpler,
> by adding a new "I support unicast Hellos" bit in the IHU Reserved field.
> That way when a node appears on a link, they send a multicast Hello,
> and get IHUs in response. If all the IHUs have this bit, then the router
> can go into unicast Hello mode. Similarly, when a node sees a new
> neighbor, it sends it an IHU with this bit and if it receives a unicast
> Hello from that node it knows they are supported, otherwise falls back
> to multicast. You could then have different intervals for multicast and
> unicast Hellos, with the multicast one being potentially much higher.
Personally I like the idea of having very infrequent multicast hellos and
common unicast ones (if called for). The extra complexity is the only downside
I see in this scheme.
I am not even sure you need separate mode for it in the specification ('all
IHUs'; tricky on e.g. adhoc); you can simply locally configure a long-ish
multicast hello interval, and opt for shorter unicast hellos if you feel like
it with consenting peers (that have indicated consent by sending IHU with
uhello support).
Mandating two separate modes should not be necessary but for QoL it might be an
implementation option anyway. Depends on how many orders of magnitude fewer you
would make normal hello interval as opposed to uhello one.
So the question becomes then whether it is worth having uhello support bit +
separate uhello message in the specification (+ some edits related to it), and
then leave their implementation details open.
> This proposal stays in the spirit of current Hellos as a measure for
> packet loss rate. If as you describe this isn't a great metric, we
> could take this thought process even further and simply get rid of
> Hellos for link quality estimation. You would still have multicast Hellos
> to detect new peers, but you can estimate by-directional reachability
> simply by noticing of you receive any Babel packet from a host, and
> IHU for the reverse direction. This makes particular sense if you were
> able to query your link-layer for information on how many
> retransmissions are required on average to reach that host, and what
> rate the Wi-Fi chip is operating at.
I am not a fan of using multicast for estimating unicast link quality anyway.
Typically, multicast drop rates are higher (IIRC, cannot be bothered to look up
a reference right now, sorry, it is 4am) than unicast ones. Therefore estimates
generated from uhellos would be better anyway.
Cheers,
-Markus
_______________________________________________
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
