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 0A9182012F7; Mon, 2 Jul 2012 09:16:37 -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 CA59340E3D; Mon, 2 Jul 2012 18:16:31 +0200 (CEST) Subject: Re: [Babel-users] switching cerowrt to quagga-babeld issues Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_5DF79D88-4222-4604-9641-8D84E21BF75D"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "L. Aaron Kaplan" In-Reply-To: Date: Mon, 2 Jul 2012 18:16:27 +0200 Message-Id: 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) X-Mailman-Approved-At: Mon, 02 Jul 2012 09:47:08 -0700 Cc: bloat-devel , Denis Ovsienko , babel-users , cerowrt-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 16:16:38 -0000 --Apple-Mail=_5DF79D88-4222-4604-9641-8D84E21BF75D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 2, 2012, at 5:36 PM, Dave Taht wrote: > 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? 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/ Abstract When routing devices rely on modems to effect communications over=20 wireless links, they need timely and accurate knowledge of the=20 characteristics of the link (speed, state, etc.) in order to make=20 forwarding decisions. In mobile or other environments where these=20 characteristics change frequently, manual configurations or the =20 inference of state through routing or transport protocols does not=20 allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is=20 necessary. 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. 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. Aaron. --Apple-Mail=_5DF79D88-4222-4604-9641-8D84E21BF75D 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/xyV8ACgkQxEgyMttZ8Yz6ngCggTAB8FWUY+Y5qAyuOKaD5PGq ploAmwf0Gh4kPHHgngfbrpDJEpwS6Eqm =vasn -----END PGP SIGNATURE----- --Apple-Mail=_5DF79D88-4222-4604-9641-8D84E21BF75D--