From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) (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 7F5E62002AC for ; Sun, 19 Jun 2011 06:19:15 -0700 (PDT) Received: by iwn34 with SMTP id 34so657292iwn.16 for ; Sun, 19 Jun 2011 06:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=u8ykHcgdUSpiLijcBup8+PumVSKbGC7KiyoYfi7M47w=; b=Phfj7Fm2LsZ5OfU2YQLaDIexNkthh82aCLKblooZkLMbOFEAUJ58xqmEdlL7UsU6cu MFY97EaVuO5WE6XBR6tBNtYC9YGxS4bhJ8j8clkLFf2+Eig4CF8BJOLu55NlYj5G0G6R pbu9PihUaKxUeo5jrYXOGnKOXfE2pSfPrmaes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=THefXdfu1IDbQSdrqTwcp2dlEHEcwIgUtgqWtAu2psGrFBKpAsMwFhFG76xQbd0ZNR Z/qhIiF+oSUP6h9e+MCHxMzi8XTIFbt6/Wy+PqG/2OKM8TvBEiMb4RNcL9/KBUxws8wr 4n6U1Vfjz73sSvC/PaP8O1pddQYBRpj7cVyk8= MIME-Version: 1.0 Received: by 10.231.68.202 with SMTP id w10mr4137389ibi.63.1308491093698; Sun, 19 Jun 2011 06:44:53 -0700 (PDT) Received: by 10.231.13.76 with HTTP; Sun, 19 Jun 2011 06:44:53 -0700 (PDT) Date: Sun, 19 Jun 2011 07:44:53 -0600 Message-ID: Subject: battling with babel and route changes From: Dave Taht To: bloat-devel@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sun, 19 Jun 2011 13:19:15 -0000 While I am totally in love with babel as a routing protocol, at the traffic volumes I'm regularly generating now, it's fairly trivial for a route change to stop a tcp stream in its tracks. [1] I'm simply not familiar enough with netlink to fix it, or even know if it can be fixed... 0) babel keeps all the routing information in it's head. It does not use the kernel metrics in particular: 1) babel installs ipv4 routes with a metric of 0, ipv6 routes with a metric of 1024 2) doing a route change via netlink seems to require=A0 a different metric =A0=A0 (or at least it did, several years ago, when the code was written) So I've been playing with the experimental babelz from Julius's darcs repo, which can be obtained from darcs get http://www.pps.jussieu.fr/~jch/software/repos/babelz/ The relevant bit of code is in kernel_netlink.c, where it calls itself recursively to handle a route change, instead of making a route change. =A0=A0=A0 if(operation =3D=3D ROUTE_MODIFY) { =A0=A0=A0=A0=A0=A0=A0 if(newmetric =3D=3D metric && memcmp(newgate, gate, 1= 6) =3D=3D 0 && =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 newifindex =3D=3D ifindex) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return 0; =A0=A0=A0=A0=A0=A0=A0 /* It is better to add the new route before removing = the old =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 one, to avoid losing packets.=A0 However, th= is only appears =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to work if the metrics are different. */ =A0=A0=A0=A0=A0=A0=A0 if(newmetric !=3D metric) { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rc =3D kernel_route(ROUTE_ADD, dest, plen= , =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 newgate, newifindex, newmetric, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 NULL, 0, 0); =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if(rc < 0 && errno !=3D EEXIST) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return rc; =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rc =3D kernel_route(ROUTE_FLUSH, dest, pl= en, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 gate, ifindex, metric, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 NULL, 0, 0); =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if(rc < 0 && (errno =3D=3D ENOENT || errn= o =3D=3D ESRCH)) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rc =3D 1; =A0=A0=A0=A0=A0=A0=A0 } else { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rc =3D kernel_route(ROUTE_FLUSH, dest, pl= en, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 gate, ifindex, metric, NULL, 0, 0); rc =3D kernel_route(ROUTE_ADD, dest, plen, newgate, newifindex, newmetric, NULL, 0, 0); if(rc < 0 && errno =3D=3D EEXIST) rc =3D 1; } -- Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com 1: lest you think this is not relevant to bufferbloat... I am generating saturating loads across two test networks [2], while trying to get real work done - saving the mice packets - you know, typing, listening to streaming radio - and fixing bloat wherever it appears - and I keep stumbling across problems like this one (assuming it's real) that aren't related to bloat but affect the tests. I THINK, but am not prepared to discuss, that I've found a long standing bug with dhcp, for example. Working on it... 2: Test network #1 - 8 wndr3700s and a pc at georgia tech Test network #2 - Linux laptop, 2 wndr3700, 3 nanostation M5s, 1 android, 1 ipad, 1 iphone, 1 nokia 770, 1 windows XP box, 1 vista box, and soon - 3 OLPCS. I'm getting to where I can grant permission for others to hack on the first network. 3: While this might be better on the babel list, I thought that perhaps in-depth netlink knowledge was here...