Re: [homenet] Updates to Homenet Architecture Principles doc

[Juliusz Chroboczek <[e-mail]>]

>> This sounds _way_ too specific to me.

> If you are just going to laugh,

Laugh with us, Ted -- it /is/ rather funny.

(I especially liked the "linear sum" touch.  What's a non-linear sum?)

> This statement should be inclusive of whatever routing protocols the
> working group is inclined to consider,

I'll do my best.  There are at least four issues at hand.

1. Not all routing protocols choose the lowest-metric route -- some
   protocols include in their route selection criteria data that are not
   encoded in the metric.  Examples are BGP flap avoidance, or the
   hysteresis algorithm used by Babel.  One might argue that this is also
   the case of multi-area OSPF (although it is not usually expressed in
   that manner).

   For BGP and OSPF, you probably know more about the subject than I do.
   For Babel, see Section 3.6 of RFC 6126 and Section III.E of

       http://arxiv.org/pdf/1403.3488

   (As far as I know, there is currently no theoretical understanding of
   this kind of techniques.  As far as I've been able to work out, neither
   Sobrinho's routing algebras nor Griffin's semigroups are able to account
   for them.)

   The Arch document MUST NOT specify what kind of data the route
   selection algorithm is allowed to take as input.


2. Many protocols don't compute metrics as a "linear sum" of the link
   costs; as a matter of fact, in many protocols the metric is not a mere
   integer, but an element of a richer algebra.  This is obviously the
   case of BGP (see Griffin and Sobrinho, SIGCOMM 2005), but also of
   Babel, which, when run over a radio link layer with interference
   avoidance enabled, carries a pair of an integer and (roughly speaking)
   a set of interfering radio frequencies.

   The Arch document MUST NOT specify the structure of the metric algebra.
   It SHOULD NOT even imply that the metric being used is modelisable as
   a routing algebra.


3. Finding a satisfactory and implementable metric for radio link layers
   is very much an open research problem.  Many routing protocols just
   punt and expect the link layer to work like an Ethernet, which gets you
   horrible performance in rich layer 3 topologies.  Some mesh routing
   protocols estimate unicast link rate and multicast packet loss and
   combine the two using magic, which tends to choose unusable routes in
   some cases.  There has been a lot of noise around cross-layer
   techniques for the last 10 years or so, but I don't know of
   a production-quality implementation.  (Yeah, I know, I should stop
   complaining and try my hand at it.)

   Please do not underestimate the importance of this point for Homenet --
   how many wired and how many wireless links do you expect there to be in
   a typical home ten years from now?

   The Arch document MUST NOT specify what kind of data the metric
   computation algorithm is allowed to take as input.


4. There exist routing protocols that don't use the notion of a metric at
   all.  We metric-based people like to jestingly call them "longest-path
   routing" algorithms, however we're still keeping an eye open to see if
   anything useful comes out from that line of research.

   The Arch document SHOULD NOT even imply that a metric is being used.


Hope this helps,

-- Juliusz