Subject: Re: [babel] babel Digest, Vol 13, Issue 3

From: Tony Przygienda <[email-masked]>
Date: Thu, 29 Sep 2016 08:58:37 -0700

inline ...

---------- Forwarded message ----------
> From: David Schinazi <[email-masked]>
> To: [email-masked]
> Cc:
> Date: Tue, 27 Sep 2016 16:01:37 -0700
> Subject: [babel] Comments on RFC 6126
> Fellow Babel enthusiasts,
>
> As a fun research project, I have built a fully independent implementation
> of Babel, exclusively from specification.

very cool, looks like this will be one of the wider implemented recent
protocols. I only remember RIP implementations sprouting that fast in its
time ;-)

> While it still has some rough edges, it works well enough for a demo and
> interoperates with devices running babeld. In the process of building it, I
> took notes on what parts of RFC 6126 were confusing to me, and also have
> written down random thoughts for parts of the document (and protocol) that
> I think could be improved. But before I dive into how the spec isn't
> perfect, let me say that it's a very well written document that allowed me
> to build my own implementation without ever looking at babeld's source
> code. These comments aren't very well organized, I'm sharing them with the
> list to start conversations that could potentially lead to changes in RFC
> 6126 bis. Feel free to shoot any questions my way.
>

Experience and good specs are all very valuable and silver, implementors
showing the thumb direction is gold. Further inline ...

>
> *) Parts of the specification that I think may be incorrect
>         • in 3.1, "a Babel speaker does not need to determine the
> destination address of a packet that it receives in order to interpret it"
> isn't necessarily true in the case of IHU TLVs with AE=0. Packets that are
> ambiguous could be explicitly forbidden but checking if we received the
> packet over unicast or multicast can be helpful.
>

Yep, from bitter experience you DO want to pay close attention how and when
your 0/0 starts to slosh around. Those can do extraordinary amount of
damage. Rules WHEN 0/0 (AE=0) is to be accepted and when dropped cannot be
strict enough.

>
>         • shouldn't the table of pending seqno requests (3.2.6) be indexed
> by routerID too? 3.8.1.2 is not clear about defining what redundant
> requests should be indexed on
>

In abstract terms, "over"-specifying a protocol is as bad as under
specifying it often. Telling people how to build/index data structures
often leads to far more confusion and less interoperability than otherwise.
A better language is often to talk about "tuples" of things that associate
together conceptually.  How those tuples are stored, accessed is strictly
internal implementation stuff.  Imagine we have infinitely deep/fast hash
tables tomorrow and you wrote all your spec assuming trees are the hottest
index thingies ;-)  (been done ;-)

>
> *) Parts of the specification / protocol that could be improved
>         • the jitter discussion concentrates on one possible solution,
> delaying and buffering, but there are other solutions such as not reseting
> timers based on outside events
>

yep, jitter spec should say "you SHALL jitter" and _maybe_ give some kind
of bound like "5% is not enough, 50% is too generous". Beyond that,
specifying how and how much jitter to do has not proven helpful in specs
IME.

>         • handling of Hellos - this deserves a thread all to itself but in
> a nutshell Hellos feel like the most constraining part of Babel. 3.4.3
> states a MUST: "if no hellos were received recently, then the cost is
> infinite" which feels too limiting, if an implementation has access to out
> of bound mechanisms for neighbor discovery and bidirectional reachability
> checks (such as from the underlying link layer), it should not be
> constrained as much. Also allowing for unicast Hellos could improve
> performance in some networks.
>

be careful what you wish for. The hellos are your belts and suspenders and
pretty much only ones you have except periodic retransmission to heal any
blackholes. Enough times one or even two-way hellos ended up mocking up a
link that couldn't carry the traffic.  IS-IS ended up all the way with
3-way hellos including MTU padding after many, many painfully learned
lessons. Optimizations are fine, being pretty conservative initially when
doing hellos pays though ...

>         • would it make sense to use split horizon over wireless when
> sharing routes over unicast? (conceptually this could be equivalent to
> treating every neighbor as the other end of a point-to-point link)
>

hmm, don't parse that, sounds intriguing ...

>         • if we get a seqno request from the same node that advertised the
> route would it make sense to treat that as a retraction?
>

I wouldn't advise that. it may be in-flight transient and next thing you
start to shake your network using yet another dynamic control loop hoping
to improve things while making e'one spin their wheels. The requests are
fragile enough as they stand as I think wrote a while ago ...

>         • what does an update with AE=0 and plen>0 mean?
>         • what do you do on outgoing seqno requests if the route in
> question has been unselected between retransmissions?
>

yup, those are the finer points of FSMs involved ... Best in such cases is
a self-stabilization (positive stability) built into the protocol.

--- tony

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 30 Sep 2016 13:10:56 +0200 (CEST)

> specifying how and how much jitter to do has not proven helpful in specs

https://en.wikipedia.org/wiki/Jitter
https://en.wikipedia.org/wiki/Packet_delay_variation

"In computer networking, packet delay variation (PDV) is the difference in 
end-to-end one-way delay between selected packets in a flow with any lost 
packets being ignored.[1] The effect is sometimes referred to as jitter, 
although the definition is an imprecise fit."

I have found that for instance people doing electronics/timing/radio, they 
seem to get very upset when "jitter" is used in the context of packet 
send/receive times.

If the spec:s are re-written, should this be fixed?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 30 Sep 2016 13:19:11 +0200

> fragile enough as they stand as I think wrote a while ago ... 

Fully agreed.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 30 Sep 2016 13:31:42 +0200

> If the spec:s are re-written, should this be fixed?

Tough call.  Jitter is the right term for Hello, IHU and Update TLVs
(deviation from the period), but for other types of TLVs, random delay
makes more sense.  I've checked Floyd and Jacobson, and they don't seem to
have a nice, compact term (they say "the addition of a random component to
the routing timer interval", which is a mouthful).

I cannot find something as good as jitter, though.

-- Juliusz