[Babel-users] babel and zeroconf

Brad Neuberg bradneuberg at gmail.com
Wed Jun 4 23:00:40 UTC 2008


Hi Luke and Juliusz! Good to hear from you. Ah, P2P DNS... thats near and
dear to my heart...

What's the context of the giant email thread below? I can glean bits and
pieces but am not sure of what the overall discussion is about.

On Wed, May 14, 2008 at 11:23 AM, Luke Kenneth Casson Leighton <
luke.leighton at googlemail.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/babel-users/attachments/20080604/3bf79fbc/attachment.htm 


More information about the Babel-users mailing list