spend time to properly separate handover 2?

[Neels Hofmeyr]

I'm on the load-based handover patches: it is adding a second handover decision
algorithm. What keeps slightly itching me about it is that it is not really
cleanly separate from the first (current) handover algorithm.

- For example, in the VTY, we have the 'handover algorithm (1|2)' command, and
  the 'handover *' namespace is shared between ho 1 and ho 2. So when I look at
  the VTY commands under 'handover', a considerable number of those apply only
  to handover algorithm 2, while some, like rxlev averaging window settings and
  similar, apply to both.  (I marked the ho2 ones in the VTY docs, but still)

- The patches also add penalty timers and ho failure counters in generic
  places. In ho algorithm 2, these penalty timers and failure counts are heeded
  and cause ho / assignment to be omitted if appropriate. Not so in ho1.

The point being, if we add a third, fourth, fifth HO algo at some point, this
would probably become a tad intransparent.

I wonder now whether I should spend time on jolly's patches to more cleanly
separate the two algorithms. For example, in the structs and code, more clearly
set and apply the penalty timers and failure counts *only* if ho algo 2 is
actually used, probably even moving all of it out to context structs only known
within the ho2 code.  (Otherwise, some code adds penalty timers which might
never be looked at or cleaned up until the conn is discarded..)

On the other hand, some shared concepts make sense to be re-used. If HO algo 3
(hypothetically) wants penalty timers as well, will separating merely amount to
code dup?

Do we want separate sets of parameters for ho1 and ho2? For example, for the
rxlev window averaging, is it better to have one setting used for both ho1 and
ho2, or do I expect each algo to remember its own rxlev averaging settings?

The current patch state kind of throws both in one pot; I tried to put some
struct members in a { }ho2 sub-struct, but it's a bit half-hearted. I'm
deciding back and forth.

Truly modularizing all of it would make for more code, like opaque struct
pointers to store context, specific to each ho algorithm, at e.g. subscr_conn;
and function callbacks to take actions in certain triggers (like setting a
penalty timer for ho failure); fully separate VTY namespaces for each algo. In
other words, a proper API, sort of like the auth algo code does. It is easier
to just patch it all in there and re-use existing members, but will that bite
us in the future...

Any thoughts?

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180212/707411de/attachment.bin>