Re: [homenet] [Babel-users] Detecting bridges

Philip Homburg <> Fri, 18 December 2015 12:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9055F1B2BFD for <>; Fri, 18 Dec 2015 04:37:25 -0800 (PST)
X-Quarantine-ID: <pFOFK_5c889K>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pFOFK_5c889K for <>; Fri, 18 Dec 2015 04:37:24 -0800 (PST)
Received: from ( [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by (Postfix) with ESMTP id E2EA41B2B3B for <>; Fri, 18 Dec 2015 04:37:23 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (Smail #91) id m1a9uHj-0000GtC; Fri, 18 Dec 2015 13:37:23 +0100
Message-Id: <>
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <87egekyteh.wl-jch@pps.univ-paris->
In-reply-to: Your message of "Fri, 18 Dec 2015 10:53:42 +0100 ." <>
Date: Fri, 18 Dec 2015 13:37:22 +0100
Archived-At: <>
Cc: "" <>, Juliusz Chroboczek <>
Subject: Re: [homenet] [Babel-users] Detecting bridges
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Dec 2015 12:37:25 -0000

>> I.e., a router on wifi announces wifi and when a router that is on wired
>> receives an announcement from a router on wifi it knows that there
>> a bridge somewhere.
>Not a bad idea, but I'm a little hesitant to implement that, since it
>would require defining a taxonomy of interface types at the protocol
>level.  (Currently the taxonomy exists in the implementation, but it
>doesn't appear in the protocol -- the protocol only knows about metrics.)

It is probably not such a good idea to literally say 'wifi', but if a 
set of metrics could be defined that describe that expected stability of a
link then a router could annouce which it has configured or discovered.

One thing to consider though, in my experience lossy links make for a very
bad user experience.

So if a disconnect happens as a result of user action, say moving a wifi
device from one room to another, then losing the link is not a bad

If links just come and go then ultimately users will just complain that the
internet is bad. If bad links are unavoidable, it is better to run a 
tunneling protocol on top of those links with forward error correction
or other mechanism to make the link more reliable.

(I.e, it might better if babel degrades gracefully, instead of trying to 
make bad links 'work')