[Babel-users] babel and zeroconf

[Luke Kenneth Casson Leighton]

On Wed, May 14, 2008 at 12:15 AM, Juliusz Chroboczek
<Juliusz.Chroboczek at pps.jussieu.fr> wrote:
> >  getting proper WAN-wide name registration and defending is _hard_.
>
>  Yes, if you want to be distributed.  You can always fake it with
>  a centralised server.

 yuk :)  yes.  e.g. WINS servers.  WINS servers - a centralised
"collection" point, aka NBNS servers in rfc1001/1002.  the "recursion
desired" flag is set to indicate the distinction between "actually
this packet should go to the WINS server" and "actually this packet
should go to the local-broadcast-network-service that is defending
this particular LAN segment".  because, obviously, a WINS server has
to be _on_ a NetBIOS network!  the "recursion desired" flag is exactly
the same bit as the DNS "recursion desired" flag (same packet format,
different meaning.  botched by microsoft's implementation! grr)


 ... or you could have a p2p-based DNS service such as that offered by
the lightweight p2p-dns replacement of
https://p2psockets.dev.java.net/ (hi brad! :) )

 freedce / dce/rpc contains a "naming service" with the ability to do
"global" naming.  i.e. you can register as being one of many of the
providers of a particular service.  the opengroup's reference
implementation (dce 1.1 aka freedce) and the subsequent release of dce
1.2.2 under the LGPL - all these codebases contain a "naming service"
which is, unfortunately, "centralised".

however, i'm mentioning the concept because i believe that a p2p
"naming service" should deeffinitely have "group registration"
support.

thus, you can have a p2p dns cache where it would be easy to find
yourself a local cache of the more "global" dns, and you would simply
begin by broadcasting out to find the nearest cache, then, on finding
one, you'd be able to query _that_ to find out further-afield
resources...

>  >  it takes about _three years_ to get it right - as no less than three
>  > of us found out for samba.
>
>  Yeah, but you needed to be bug-compatible with another system.  Doing
>  it from scratch would have been easier.

 ... you'd think so... :)  but we learned that it took microsoft three
years to get their _own_ implementation correct ha ha.

>  >>  In a mesh network, the notion of link doesn't really
>  >>  exist, so zeroconf will give mixed results.
>
>  > ... this i don't follow.  you're using terms that have specific
>  > meanings with which i'm not yet familiar, and, as it's an area i
>  > really do need to understand, i'd very much appreciate some pointers /
>  > elaboration.
>
>  Sure.  In traditional (wired) networking, a link is a set of
>  interfaces that can communicate without going through a router.

 oh ok.

>  It
>  used to be just a cable, nowadays it's usually a set of cables bridged
>  together.

 oh, as simple as that? ok he he.

 ok - so... going back to the original thing you said - that "in a
mesh network, zeroconf can't really cope because 'link' doesn't really
exist", a mesh network is where you have limited (unreliable)
connectivity between nodes.

soo... http://wiki.laptop.org/go/Mesh_Network_Details#Experimenting -
they've ... oh.  they cheated.  they got marvell to do some of the
low-level mesh networking.  y'know... i get deeply unimpressed, more
and more, with the OLPC's management, the more i hear about it.

so anyway, that explains why zeroconf can do what it does on OLPC,
because the mesh networking side is "taken care of" in hardware.


>  In both IPv4 and IPv6, you usually assume that if a node belongs to
>  the same subnet prefix as you do then it is on the same link, and you
>  may speak to it directly (ignoring unnumbered links and multiple
>  prefixes per link for now).  In other words, you encode topology
>  information within the bits of the address.

 ack.

>  Obviously, this is not the case for mesh networks, where the topology
>  varies over time and does not correspond in any way to the address
>  allocation.

 ack.

>  > in particular, what does - or doesn't - babel provide for "mesh networks" ?
>
>  Babel is a routing protocol that, in its basic form, does not make any
>  assumptions about how prefixes map to links.  Hence, it will work on
>  any network topology -- wireless mesh, classical wired network --, but
>  might not be optimally efficient.

 doesn't matter :)

>  Babel can be made to be efficient on wired networks, but this requires
>  a little bit of per-node configuration.  Since most of our nodes are
>  wireless, and at any rate the inefficiency incurred by using
>  out-of-the-box Babel on wired networks is slight, that's satisfactory.

 ack.

>  The only assumption that Babel makes about the underlying network is
>  that link-local multicast is able to reach all neighbours.

 ahh :)  that would be where a "group-based" p2p "name registration"
concept would come in handy: you could use it to maintain an
approximation of link-local, based on aggregation of successful links
and partially-successful links (which would sometimes require one hop
and would sometimes drift in-and-out of direct contact).

and use this aggregated list to pseudo-define a slightly more stable
multicasting group, comprising immediate neighbours plus
one-hop-neighbours.

... what you think?  does this sound even remotely practical - or useful?

>  Hence, in
>  its current form, it will not work on non-broadcast (NBMA) networks,
>  such as ATM.

 ack.

>
>  >  mm? *quizzical*.  i thought ipv6 didn't do multicasting?
>
>  IPv6 multicasts just fine.

 oh.  huh.  i must have something misunderstood (from my friend who
maintains his own node and gets a BGP feed etc. etc. - i'll have to
ask him what that's about).

>  However, non-local multicast requires
>  multicast routers, and Babel doesn't route multicast right now.
>
>
>  > the lowest speed network is a digital radio modem, with something
>  > like a 10 mile range (with TCP/IP on it).
>
>  How does that Simpsons line go again?  Mmmh... 800MHz.

 he he

>
>  > the other ones we have yet to specify but candidates include
>  > GPRS/EDGE or maybe 3G, and WIMAX or some other adhoc high speed
>  > networking.
>
>  What do you mean by ``ad-hoc''?  If you're using the term to mean that
>  stations can communicate between themselves, then WiMAX certainly
>  isn't, it's strictly a point-to-multipoint technology.  (Which is
>  something that Babel will handle beautifully, by the way.)

 ooo, cooool :)

>  > please don't ask why all that's needed :)
>
>  Please do tell!

 ha ha.

well, the voice data goes over the radio-modem, but the baud rate is
nowhere near enough to do video, which is one of the requirements.
and the radio-modem "black box" has mesh networking built-in and it's
all "taken care of" as far as i can tell...

... which leaves us completely buggered for transferring video content
between devices.  and pretty much everything else.

so, not only am i going to need to merge all the different types of
communications technology together but also i'm going to need to send
certain types of traffic (voice, video, jpeg images) over the
different communications networks, selecting the "best available" one
for the job. (!)

>  > so i am suddenly extreemely interested in decent and versatile routing
>  > software that can help here!
>
>  Babel is certainly versatile, and I like to think it's decent.  It can
>  deal with multiple interfaces, which appears to be what you are mainly
>  concerned with.

 yes.  ppp over GSM/GPRS; WIMAX; 802.11; radio-modem; all of it has to
be sort-of... merged amorphously.

what i am hoping is that the use of (at least two) extra
communications channels will be very helpful in ensuring that the
other channels are made best use of.

e.g. if you can transfer _some_ routing information - however slowly -
about the 2-mile-range WIMAX nodes over the 10-mile-range radio-modem,
then you would, i assume, be able to make better routing decisions
than you would if you didn't have the long-range radio connection?


>  But you'll really need to tell us more about the network architecture
>  you're envisioning.  Whether Babel or some other technology is best
>  depends on a lot of factors,

 ok.

> notably what kind of hand-off times are tolerable,

 walking around inside and outside office buildings, which might cut
things off randomly, but assume decent antenna (4 or 8-way phased
ceramic antenna).

> whether you're interested in multi-hop routing,

like http://wiki.laptop.org/go/Mesh_Network_Details#Experimenting ? yes.

so - like the OLPC thing [except better :) ]  assume that it's got to
work without centralised infrastructure, but if centralised
infrastructure is available (e.g. GPRS / 3G or a high-power
fixed-position WIMAX unit that has better range and coverage than the
mobile units) then it should be seamlessly taken advantage of.

>  how large is your power budget,

 luggable rather than portable.  i.e. "big enough" to not have to worry about :)

>  and whether you can count on link-layer notifications.

 does this mean "inter-layer" notifications?  i.e. like i hinted at
above, about being able to send notifications over the radio-modem
about the e.g. WIMAX layer?

 if so, yes.

 l.