Re: [babel] route expiry timers for rebroadcast?

Juliusz Chroboczek <jch@irif.fr> Mon, 20 February 2017 02:31 UTC

Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891F2129624 for <babel@ietfa.amsl.com>; Sun, 19 Feb 2017 18:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjAw-yhJ58yv for <babel@ietfa.amsl.com>; Sun, 19 Feb 2017 18:31:29 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E6712943A for <babel@ietf.org>; Sun, 19 Feb 2017 18:31:27 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v1K2VPtD011933; Mon, 20 Feb 2017 03:31:25 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 73D26D7A15; Mon, 20 Feb 2017 03:31:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qnJQLIT35cZo; Mon, 20 Feb 2017 03:31:24 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9D979D79EF; Mon, 20 Feb 2017 03:31:23 +0100 (CET)
Date: Mon, 20 Feb 2017 03:31:23 +0100
Message-ID: <87zihhfv9g.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Dave Taht <dave.taht@gmail.com>
In-Reply-To: <CAA93jw7eXu0xze=wZY0EzhV5Y0SMqcYPC4kxoPqJpgUdXnwUgw@mail.gmail.com>
References: <CAA93jw7eXu0xze=wZY0EzhV5Y0SMqcYPC4kxoPqJpgUdXnwUgw@mail.gmail.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 20 Feb 2017 03:31:25 +0100 (CET)
X-Miltered: at korolev with ID 58AA54FD.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 58AA54FD.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 58AA54FD.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/ekufesFHdhCkeo3IxKaQtY06Hs4>
Cc: Babel at IETF <babel@ietf.org>
Subject: Re: [babel] route expiry timers for rebroadcast?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2017 02:31:30 -0000

> where it would make some sense to also bound the client router's
> recieving that update to rebroadcast advertising the interval field to
> some amount less than the received interval, or to the actual
> bandwidth available on an interface, but still broadcast as
> catch-can...

I think there's some confusion here.  These are two distinct timers -- the
route expiry timer (Section 3.2.5) and the update timer (Section 3.2.2).
The route expiry timer is governed by the Interval value advertised by the
peer (last bullet point in Section 3.5.4), while the update timer triggers
at fixed intervals.

There is indeed an omission in the spec -- Section 3.7.1 does not
precisely say how to deal with the update timer, it merely says that the
updates are sent periodically.  As you justly guessed, the protocol is
robust enough to allow varying the period depending on external factors
(e.g. network load), but finding the right heuristics is probably an open
research problem -- the only thing that rings a bell is the pacing of
refloodings in IS-IS, but that's a very different issue from pacing
updates in a distance vector protocol.

-- Juliusz