Subject: [homenet] routing protocol metric

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Jul 2015 15:22:05 +0200 (CEST)

Hi,

I have just taken for granted that hnetd/HNCP would have functionality to 
configure routing protocol metric per interface. When I talked about this, 
I got feedback that seemed to indicate that I was very wrong (to put it 
mildly).

May I ask why this design decision was made? For me a routing protocol 
doesn't autoconfigure its metrics, but I now realise that this is probably 
what babel does? I thought the mechanism of configuring the metrics was 
separated logically, but I now realise this isn't how it has been done in 
babel?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jul 2015 09:23:56 -0400

On Jul 22, 2015, at 9:22 AM, Mikael Abrahamsson <[email-masked]> wrote:
> May I ask why this design decision was made? For me a routing protocol doesn't autoconfigure its metrics, but I now realise that this is probably what babel does? I thought the mechanism of configuring the metrics was separated logically, but I now realise this isn't how it has been done in babel?

HNCP doesn’t have the information it needs to set a metric.   Babel figures out the metric using an adaptive mechanism that could be put into HNCP, but isn’t currently in HNCP.

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 22 Jul 2015 17:10:56 +0200

Just throwing an argument that comes into my mind here.

HNCP advertises configuration. Long-lived things. 
It is likely that DNCP is quite inefficient when it comes to changing things all the time.
Metrics can evolve. Particularly wifi links metrics. So we probably do not want to put that in DNCP.

- Pierre

> Le 22 juil. 2015 à 15:23, Ted Lemon <[email-masked]> a écrit :
> 
> On Jul 22, 2015, at 9:22 AM, Mikael Abrahamsson <[email-masked] <mailto:[email-masked]>> wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 22 Jul 2015 18:17:20 +0200

> On 22.7.2015, at 17.10, Pierre Pfister <[email-masked]> wrote:
> 

I am not sure how well e.g. ISIS deals with constantly changing link metrics either (hello, constant link state db sync).

So there would have to be some sort of hysteresis and e.g. just orders of magnitude different metric changes reported in any case.

(Feel free to correct me if I am wrong, while I have had something to do with some IS-IS implementation in the bast, read book or two, and half the specs, I am far from expert.)

Building the mechanism in-band in IS-IS would be better in this case anyway as the link state database churn would map 1:1 to metric churn _anyway_.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 22 Jul 2015 18:38:59 +0200

> configure routing protocol metric per interface.

Babel is designed to cope with metrics that change continuously (on the
order of seconds, much faster than what HNCP is designed to deal with),
and it has a number of mechanisms that refrain from announcing small
metric changes -- intuitively, Babel will reconverge quickly if it loses
its selected route, but will delay announcements and reconvergence if the
current route is good enough, just not the best.

The reason that works is because Babel has a strong loop avoidance
mechanism -- the intuition is that if you're going in roughly the right
direction while guaranteeing loop-freedom, there's not much that can go
wrong.  I believe that this is difficult to do in link state, but David
Lamparter has been doing impossible things lately, so I'll refrain from
making any stronger statements.

The current code implements three different metrics:

  - Appendix A.2.2 of RFC 6126 defines a simple packet-loss metric (ETX);

  - draft-chroboczek-babel-diversity-routing defines a metric that takes
    radio interference into account;

  - draft-jonglez-babel-rtt-extension defines a metric that is suitable
    for intercontinental overlay networks.

Of course, all of these extensions interoperate with the base spec, with
each other, and with source-specific routing.  And all of them are being
used in production.

The packet-loss metric is evaluated in [1].  The overlay network stuff is
evaluated in [2].  No formal evaluation has been done of the radio
interference metric, which is something I really need to do ASAP -- we're
the only routing protocol that does something like that as far as I know.

[1] M. Abolhasan, B. Hagelstein, J. C.-P. Wang. Real-world performance of
    current proactive multi-hop mesh protocols. Asia-Pacific Conference on
    Communication (APCC 2009), Shanghai, China. 2009.
    http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers

[2] B. Jonglez, M. Boutier and J. Chroboczek. Delay-based routing.
    Draft.  http://arxiv.org/abs/1403.3488

If people are interested, there's a 50-minutes talk about Babel that I've
given before, we could grab a projector and have me speak about my
favourite subject.

-- Juliusz

---

From: David Lamparter <[email-masked]>
Date: Wed, 22 Jul 2015 19:40:09 +0200

On Wed, Jul 22, 2015 at 06:17:20PM +0200, Markus Stenberg wrote:
> I am not sure how well e.g. ISIS deals with constantly changing link
> metrics either (hello, constant link state db sync).
> 
> So there would have to be some sort of hysteresis and e.g. just orders
> of magnitude different metric changes reported in any case.

You're completely right;  you have the free choice on when and why to
update a particular metric IS-IS, and the right thing to do is not do it
every 0.01s.

However, you're wrong in implying that the constant link state db sync
would be largely different in a distance vector protocol.

In a DV protocol, you can:
- choose to delay propagating updates that *lower* metric for a prefix
- not propagate updates that are not selected

In a LS protocol, you can:
- send smaller updates when lots of prefixes are on a single router
- not propagate updates that you know the peer is aware of, even if that
  means the peer's path is through you

(the latter happens when routing information propagates slowly on a
low-metric high-latency path, but quickly on a high-metric low-latency
path)

Either way when you're changing some metric, you need to start
distributing that.  Neither LS nor DV have "absolute" immediate
advantages.  (Which is why lots of large networks run LS IGPs
internally, but we're using DV/BGP on the internet at large.)

-David

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 23 Jul 2015 02:34:32 +0200

[CC trimmed]

> - choose to delay propagating updates that *lower* metric for a prefix

You can delay all updates except retractions.

> - not propagate updates that are not selected

I think you're confused -- a distance-vector protocol never sends updates
for unselected routes in the first place.

-- Juliusz