From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 34A5621F1FF for ; Tue, 7 Apr 2015 13:44:22 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so34879516obb.3 for ; Tue, 07 Apr 2015 13:44:22 -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=g9zOp/WpnEsHPxDsTQJjK3jAT4az9TRaLWb3C2PjI1k=; b=vVxH0ahOUb2Nz0w6MvxMK8/gGkVA77rE4qDGlo4AATj4+PD9khQbBfpSYbmvjjEDp1 xecFXXB02mn6mcqmNaGgtT9gQbIiGrzFWybZYeFgs3BSXuStdyAgtZ2wiDmtfhsiYjrl bLciKkeqFHjbI6Ee25rXRsCqlTeC+QObziBUusivB4tpZmav7Nh8lcztv4Im3cQ2MZpz hRtouRx3OxeavB1qyoJ3gFARi4Hc1yfUvjygFp5QXObmext2C97NrZhKun/XtndJ+2a0 k5xYN2X81pY6nNx6jHGG2tNwZRCUPI0FSq7smXOCoLTgzeUx19uzNJ1PEqHh7O5smerD 481A== MIME-Version: 1.0 X-Received: by 10.182.66.106 with SMTP id e10mr27515443obt.42.1428439461926; Tue, 07 Apr 2015 13:44:21 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Tue, 7 Apr 2015 13:44:21 -0700 (PDT) In-Reply-To: <87zj6jfzu1.wl-jch@pps.univ-paris-diderot.fr> References: <87zj6jfzu1.wl-jch@pps.univ-paris-diderot.fr> Date: Tue, 7 Apr 2015 13:44:21 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Andrew McGregor , "babel-users@lists.alioth.debian.org" , "cerowrt-devel@lists.bufferbloat.net" , Felix Fietkau Subject: Re: [Cerowrt-devel] [Babel-users] more wet paint - babel unicast IHU for short-rtt path optimization 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: Tue, 07 Apr 2015 20:44:51 -0000 On Tue, Apr 7, 2015 at 1:28 PM, Juliusz Chroboczek wrote: >> My understanding of the babeld code is that unicast code is in there >> but not used, and if it were used, it would not work against existing >> babel daemons. ? > > You MAY send any Babel TLV over unicast except a Hello. Hellos MUST be > sent over multicast. The receiver doesn't care (except for Hellos). > > Look at message.c, function send_ihu. around line 1693. If there's > already a unicast TLV queued, then the IHU is appended to that, and sent > over unicast. Otherwise, the IHU is appended to the multicast buffer. cool. > There would be no problem sending all IHUs over unicast, but it would > probably cause additional NDs. On idle networks it would have an added cost of 1ND per idle station per minute (? dont remember how long the ND cache lasts). Otherwise, free. >A more productive endeavour would be to > send updates over unicast when there are few neighbours on a given > interface, but I'm afraid it might cause Babel more difficult to debug. That would give the needed packet volley for free on larger networks. (see item 8 on TL;DR :) ) A timestamp is not defined for updates, presently. Do you fragment? Would an IHU be bundled with an update? Reading the tcpdump code (almost done updating it for tcpdump git head, maybe another hour) was most productive in understanding the guts of the protocol, btw. I guess I am better at reading code than RFCs. > > -- Juliusz --=20 Dave T=C3=A4ht We CAN make better hardware, ourselves, beat bufferbloat, and take back control of the edge of the internet! If we work together, on making it: https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hard= ware-for-networking