Re: [babel] Open issues with draft-ietf-babel-rtt-extension

Baptiste Jonglez <baptiste.jonglez@imag.fr> Thu, 25 July 2019 14:57 UTC

Return-Path: <baptiste.jonglez@imag.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 3EE6A1200E3 for <babel@ietfa.amsl.com>; Thu, 25 Jul 2019 07:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level:
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 e5K7t7Y3lsza for <babel@ietfa.amsl.com>; Thu, 25 Jul 2019 07:57:18 -0700 (PDT)
Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDB912006D for <babel@ietf.org>; Thu, 25 Jul 2019 07:57:15 -0700 (PDT)
Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id 1A01CA0385; Thu, 25 Jul 2019 16:57:13 +0200 (CEST)
Received: from smtps.univ-grenoble-alpes.fr (smtps.univ-grenoble-alpes.fr [152.77.1.30]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id 0C993E00A3; Thu, 25 Jul 2019 16:57:13 +0200 (CEST)
Received: from imag.fr (blaine.imag.fr [129.88.55.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jonglezb@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id 0877C125EB7; Thu, 25 Jul 2019 16:57:13 +0200 (CEST)
Date: Thu, 25 Jul 2019 16:57:11 +0200
From: Baptiste Jonglez <baptiste.jonglez@imag.fr>
To: Toke Høiland-Jørgensen <toke@toke.dk>
Cc: Juliusz Chroboczek <jch@irif.fr>, babel@ietf.org
Message-ID: <20190725145711.vwklw4epew3tkxgo@imag.fr>
References: <87k1c75cn5.wl-jch@irif.fr> <878ssmz83p.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="zsup3qazi7dajz3x"
Content-Disposition: inline
In-Reply-To: <878ssmz83p.fsf@toke.dk>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Greylist: Whitelist-UGA SMTP Authentifie (jonglezb@univ-grenoble-alpes.fr) via smtps-465 ACL (112)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/Pe77ba_dnibCopnQlz033BvjxMI>
Subject: Re: [babel] Open issues with draft-ietf-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: Thu, 25 Jul 2019 14:57:21 -0000

On Thu, Jul 25, 2019 at 01:06:34PM +0200, Toke Høiland-Jørgensen wrote:
> Juliusz Chroboczek <jch@irif.fr> writes:
> > 2. Decoupling timestamps from Hello
> >
> > Currently, the timestamp data is sent in two pieces:
> >
> >   - Hello contains the transmit timestamp, which is the same for all
> >     neighbours;
> >   - IHU contains the receive timestamp and the timestamp echo, which are
> >     per-neighbour.
> >
> > This makes a lot of sense -- after all, IHUs contain per-neighbour data,
> > while sender data is contained in Hellos.  OTOH, it means that an IHU's
> > timestamp can only be interpreted if it is sent in a packet that contains
> > a Hello TLV.
> >
> > Baptiste outlined two solutions:
> >
> >   (a) require that all IHUs be sent in packets with a Hello;
> >   (b) define a new TLV that contains just a timestamp.
> >

Thank you for summarizing.  You apparently didn't like my "Solution 1"
because you don't even mention it, but I agree it's a bad idea anyway :)

The slides of my presentation are here: https://datatracker.ietf.org/meeting/105/materials/slides-105-babel-delay-based-metric-extension-for-the-babel-protocol-00

> > In RFC 6126bis, we defined Unicast Hellos and Unscheduled Hellos, which
> > should in principle make approach (a) easy to implement.  I'd be very
> > grateful if people could look very carefully at the new kinds of Hello,
> > and decide whether these mechanisms are enough, or whether we need a new
> > kind of TLV so we can avoid sending spurious Hellos.
>
> I haven't looked very carefully, but I think you are probably right that
> we *can* make do with this. A separate timestamp TLV seems
> architecturally cleaner to me, though, although I can't really explain
> why...

I also think unicast/unscheduled Hellos can make (a) work without further
hacks, but indeed it feels somewhat uncomfortable that Hello messages are
used for several roles (neighbour discovery and maintenance, link quality
estimation, RTT estimation).  It works if these roles don't conflict, but
it's walking on a tightrope, as the Unscheduled Hello "hack" shows.

The main issue is that we lack practical experience on this: I didn't
check all implementations, but it seems that nobody actually implemented
unicast Hellos yet?

-- 
Baptiste Jonglez
PhD student
Univ. Grenoble Alpes <https://www.univ-grenoble-alpes.fr/>
LIG lab <https://www.liglab.fr/>
Drakkar team <http://drakkar.imag.fr/>  |  Polaris team at INRIA <https://team.inria.fr/polaris/>