[Babel-users] About latency-based metrics [was: A happy babel user: re6st]

[Juliusz Chroboczek]

>     > I told you last summer, I've come up with a cool way to measure
>     > latency without increasing the amount of traffic much, so now it's
>     > a simple matter of programming.

> awesome. in time for IETF?

Could do.  I'm invited?

> I note that my (side?) of the work has been on reducing per-hop
> latency under load

I think that's pretty much orthogonal.

A route's RTT is the sum of two components: the natural delay (mostly
due to signal propagation and store-and-forward delays), and the
queuing delay.  JP is using fairly uncongested links, and what he's
concerned about is the former.  Consider the following topology:

    Tokyo
     . .     There's a pair of stable tunnels to Tokyo, RTT = 500ms
    .   .
   A-----S   We're trying to send user data from A to S
    \   /
     \ /     The solid lines are local Ethernets, RTT < 1ms
      B

Suppose now that the direct link from A to S breaks -- since packet
loss is 0% on both the local links and the tunnels, Babel might (with
a 50% chance) send the traffic through Tokyo.

Note that, barring manual configuration, latency is the only bit of
information we have that allows us to distinguish the Ethernets from
the tunnels.  Unfortunately, using latency naïvely leads to unbounded
oscillations in some cases due to the discontinuous feedback between
routing decisions and queueing delay.  I /think/ that I now have
a design which I /believe/ might (or might not) have the following
properties:

  - oscillations are bounded in all cases;
  - the frequency of oscillations is bounded;
  - if an equilibrium exists, then it will be found with high probability.

Unfortunately, the maths of the problem is beyond me, so don't expect
anything more than some rough intuitions for the time being.

> CAP can induce 200ms of delay or more

You mean 802.11-style power saving?  I think that's okay, since it's
a bounded delay that only happens when there is no load -- under load,
the power-saving timeout will never trigger.

-- Juliusz