From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7ACC420029B; Mon, 2 Jul 2012 09:44:23 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so2745849wib.10 for ; Mon, 02 Jul 2012 09:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O5vZDVTAVoxmva46+knpYZkBAbioJjJL4h4iFkE+o3I=; b=zw1/zxAacKCUxTmfCgS8DXrZ9Sg1ayJncctk6xrAfAownatnMpmVIJRHZ0Ju1wmlhP nXXM6ogLgVL2u9IgNcRC1rsW9jvcgYLrhQmM4MXqGFf/1VerVGaEtHh2F6WOOiV6De8J lsASEgW7ohDQ7VHS5sXLoua7VkKOh+W1QPmpooFuYiKDc+MfbW/C1TVLsHrIykNyAQUZ tCdLurBVxbW6g+cs2kTMJhUppr6xk7L5vxzijFJctMRWBGbsjPRr+RyJHjPUIV4zq+5u lJQ/EZtr/SvYpONmo2oot6kk8ObXttHEsRgeuuHVFP48SZgBpeKEStBU9bRsLozp7Hzk qWXQ== MIME-Version: 1.0 Received: by 10.180.105.163 with SMTP id gn3mr24747145wib.2.1341247461414; Mon, 02 Jul 2012 09:44:21 -0700 (PDT) Received: by 10.223.103.199 with HTTP; Mon, 2 Jul 2012 09:44:21 -0700 (PDT) In-Reply-To: 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> Date: Mon, 2 Jul 2012 12:44:21 -0400 Message-ID: Subject: Re: [Babel-users] switching cerowrt to quagga-babeld issues From: Dave Taht To: "L. Aaron Kaplan" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:44:24 -0000 On Mon, Jul 2, 2012 at 12:16 PM, L. Aaron Kaplan wrote: > > On Jul 2, 2012, at 5:36 PM, Dave Taht wrote: > >> How goeth ipv6? >> >>> >>> The project may get more options, if we drive the prototype towards a f= inished deliverable. >> >> I am very enthusiastic about babel's new authenticated mesh routing! >> >> 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.... >> >> 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 currentl= y implementing: DLEP - a (mostly routing protocol independent) framework fo= r 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 > 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. > > > > More info and code samples on the olsr.org git repo. I'd like to also enc= ourage Babel coders to take a look at it and collectively improve this. I just did. I like it. 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. 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. > It will be - as Dave already mentioned - anyway a hard problem to have th= is working for many radios in a standardized way, so it would really be hel= pful if different mesh developers for once could work *together* on some ge= neral feature which improves everybody's metrics. YES! Please, can we mesh people find a way to work together for a change? 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 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? 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. I also note that I am intensely dissatisfied with babel's current metric, which is basically "ping" over multicast, but I'm happy as babel's metric is pluggable and can be changed. > > Aaron. > --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out with fq_codel!"