Re: [babel] Do we want to adopt draft-jonglez-babel-rtt-extension?

Toke Høiland-Jørgensen <toke@toke.dk> Sat, 09 March 2019 15:27 UTC

Return-Path: <toke@toke.dk>
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 22870127917 for <babel@ietfa.amsl.com>; Sat, 9 Mar 2019 07:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
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 frEw2_JZAdXe for <babel@ietfa.amsl.com>; Sat, 9 Mar 2019 07:27:22 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2a00:7660:6da:2001::664]) (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 294A5127598 for <babel@ietf.org>; Sat, 9 Mar 2019 07:27:22 -0800 (PST)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1552145237; bh=d7JrPs4jy+pnDk2m/CHqYcenjOsexCLXUHwNhRFameI=; h=From:To:Subject:In-Reply-To:References:Date:From; b=dSJrigm/F0+ToxXn5zSGHGtIVOIFc2mJeW6hXbl386mbyfitfWsbkWOa1dOuVyN9z dlYioqbRAE53zqKppB9HVbt/AcLGdQknv7V0n+lNsOUVe4B8+JDaQCNazaXfgaWFyN Zxf+IZpo97q02ufOKZMRHGvolWT13bkAUsKgz4HxYlFClnR3IBUYvXSN0wm2jSkzvJ lN3w0r+4lnfZ3JR8O3jrIQB/GyNgxw7vC9FhO5ebWEUeNDvHGwI0sr+JmBg4f1Axhg UmdxvH5TQ6d2gzjlkhV2vj9OsjtuW703diXN0YFGYVc2stcWRTy3FVVhKUkcnAonSj Ykt4Ghsw0Op8Q==
To: Juliusz Chroboczek <jch@irif.fr>, babel@ietf.org
In-Reply-To: <87h8cckrn5.wl-jch@irif.fr>
References: <87h8cckrn5.wl-jch@irif.fr>
Date: Sat, 09 Mar 2019 16:27:17 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <875zss5aqy.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/EPr2zV_daVB434XEN7XPY067dM4>
Subject: Re: [babel] Do we want to adopt draft-jonglez-babel-rtt-extension?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 09 Mar 2019 15:27:25 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

> Dear all,
>
> Of all the Babel protocol extensions, the ones that are used in production
> are all IETF WG documents.  Except draft-jonglez-babel-rtt-extension.
>
>   https://tools.ietf.org/html/draft-jonglez-babel-rtt-extension
>
> Draft-jonglez-babel-rtt-extension consists of one non-mandatory sub-TLV
> that can be carried on Hello and IHU packets.  It contains enough data to
> apply Mills' algorithm (the one used in the HELLO routing protocol and
> later in NTP) in order to compute an estimate of RTT with microsecond
> granularity.  The draft only specifies how to compute RTT -- using RTT for
> something useful is left to the implementation -- but it gives an example
> of using RTT in order to derive link cost.
>
> The algorithm is described in more detail in
>
>     https://arxiv.org/pdf/1403.3488.pdf
>
> The actual motivation is overlay networks, where a single hop might span
> continents, and least-hop routing yields suboptimal results.  The
> algorithm has been used in production for a few years now by a French
> company called Nexedi.
>
> The same subprotocol could probably be used in other kinds of networks,
> most notably congested wireless networks.  More experimentation is needed.
>
> Personal opinion -- the algorithm as described in the draft has one flaw:
> since the IHU sub-TLV does not carry a Transmit timestamp, the IHU sub-TLV
> is only useful in cases where the same Packet contains a Hello TLV.  I'm
> not sure if people would be happy with a flag day, so fixing that would
> require either eating up another sub-TLV number, or putting the Transmit
> timestamp at the very end of the sub-TLV (which would make for an ugly
> format).
>
> Do we want to adopt this draft?  I can easily upload a new revision before
> Monday's cutoff date.

I was planning to eventually implement this anyway, so sure, I support
adoption :)

-Toke