From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mate.lo-res.org (unknown [IPv6:2a02:60:4:300::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B4D5C20029B; Mon, 2 Jul 2012 09:55:23 -0700 (PDT) Received: from [IPv6:2a02:850:2:2:2887:a1a:4826:9c75] (unknown [IPv6:2a02:850:2:2:2887:a1a:4826:9c75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mate.lo-res.org (Postfix) with ESMTPSA id 9819040E38; Mon, 2 Jul 2012 18:55:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_F6803606-3D30-43DC-A625-D2391298FF25"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "L. Aaron Kaplan" In-Reply-To: Date: Mon, 2 Jul 2012 18:54:52 +0200 Message-Id: <8D0DDFD9-CB7D-4157-91EA-E4DB7D95B2BB@lo-res.org> References: <2187151341044351@web9d.yandex.ru> <7isjdcpm1q.fsf@lanthane.pps.jussieu.fr> <40851341093226@web25d.yandex.ru> <7ik3yoz7p2.fsf@lanthane.pps.jussieu.fr> <1521341229978@web13h.yandex.ru> To: Dave Taht X-Mailer: Apple Mail (2.1278) Cc: bloat-devel , babel-users , cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Babel-users] switching cerowrt to quagga-babeld issues X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 16:55:24 -0000 --Apple-Mail=_F6803606-3D30-43DC-A625-D2391298FF25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 2, 2012, at 6:44 PM, Dave Taht wrote: > On Mon, Jul 2, 2012 at 12:16 PM, L. Aaron Kaplan = wrote: >>=20 >> On Jul 2, 2012, at 5:36 PM, Dave Taht wrote: >>=20 >>> How goeth ipv6? >>>=20 >>>>=20 >>>> The project may get more options, if we drive the prototype towards = a finished deliverable. >>>=20 >>> I am very enthusiastic about babel's new authenticated mesh routing! >>>=20 >>> It is also my opinion that without a decent drop and packet mixing >>> strategy that mesh networks will perform badly under load. I'm = hoping >>> that fq_codel does well, although it seems very likely that an >>> aggregation aware and fq_codel-like strategy needs to move into the >>> mac80211 layer, which is perhaps years worth of work. >> Or have better cross-layer communication - see below.... >>>=20 >>> What would a deliverable look like? What would interest people = enough >>> to get some good data, papers written, progress made, more >>> users/developers and cash in the door? >>=20 >>=20 >> I would like to point you towards a nice feature that Henning is = currently implementing: DLEP - a (mostly routing protocol independent) = framework for communicating settings and metrics between a radio and a = routing daemon. >> See https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ >>=20 >> Abstract >>=20 >>=20 >> When routing devices rely on modems to effect communications over >> wireless links, they need timely and accurate knowledge of the >> characteristics of the link (speed, state, etc.) in order to make >> forwarding decisions. In mobile or other environments where these >> characteristics change frequently, manual configurations or the >> inference of state through routing or transport protocols does not >> allow the router to make the best decisions. A bidirectional, = event- >> driven communication channel between the router and the modem is >> necessary. >>=20 >>=20 >>=20 >> More info and code samples on the olsr.org git repo. I'd like to also = encourage Babel coders to take a look at it and collectively improve = this. >=20 > I just did. I like it. >=20 Nice :) > I note that minstrel also supplies currently unreachable-via-api > information as to rates and retries that would be useful to be > exposed, but has a higher complexity than the above spec. > (note I only just read it, soo...). Andrew mcgregor has a > too-big-for-the-MPU paper on how minstrel works he's been distributing > privately. >=20 > Also I was fiddling with supplying GPS data and sensor data (over > babel, but it's not the best choice) both for more optimal wifi access > and for a prototype of an earthquake early warning system... and I'd > argue that GPS (and GPS time) data is generally useful and gps's are > now everywhere, a good way to distribute it could be added to the > above. >=20 >> It will be - as Dave already mentioned - anyway a hard problem to = have this working for many radios in a standardized way, so it would = really be helpful if different mesh developers for once could work = *together* on some general feature which improves everybody's metrics. >=20 > YES! Please, can we mesh people find a way to work together for a = change? Absolutely! >=20 > my own work on bufferbloat to a large extent is driven by a (5 years > worth of) quest to solve the "dense mesh" problem that OLPCs had. The Oh!... I remember being at One Kendall Sq. and discussing this with = Michailis LOL... I know exactly what you mean :) 30 XOs in close proximity was a recipe = for disaster :) > fq_codel work at least theoretically (but currently at the wrong > layer) is a means to improve that for all wired/wireless networks and > any given mesh protocol in particular would benefit. I have been > tracking batman-adv as well, but not olsr to any extent. Where does > "working code" lie? olsr.org/git/ What you are looking for in particular is: http://www.olsr.org/git/?p=3Dframework.git;a=3Dsummary and DLEP: http://www.olsr.org/git/?p=3Ddlep_app.git;a=3Dsummary >=20 > I note that fq_codel throws an interesting congestion-related stat > away right now, which I'd like to find a way to include in a route > metric. >=20 > I also note that I am intensely dissatisfied with babel's current > metric, which is basically "ping" over multicast, but I'm happy as ;-) the dirty little secret is : all of the current mesh protos have = unsatisfactory metrics :) > babel's metric is pluggable and can be changed. Same for OLSR. Good design choice. Okay, Dave . I recommend that you get a grip on the DELP draft and get = in touch with Henning. I shifted more towards the "making things happen" side of mesh R&D than = to the implementation side. So you need to talk with Henning in this = respect. I would love to see a common framework - well tested and = hardened by multiple developers which is usable for all of us. Aaron. --Apple-Mail=_F6803606-3D30-43DC-A625-D2391298FF25 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk/x0mAACgkQxEgyMttZ8YyueACgsoYjiAj+iALY//LPXfNjcf9f etYAoKY82Dsvay18xwK5kHUN54rnFmsg =US+q -----END PGP SIGNATURE----- --Apple-Mail=_F6803606-3D30-43DC-A625-D2391298FF25--