Re: [babel] New Version Notification for draft-ietf-babel-rtt-extension-06.txt

Toke Høiland-Jørgensen <toke@toke.dk> Wed, 17 April 2024 19:24 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 12443C14F6A3 for <babel@ietfa.amsl.com>; Wed, 17 Apr 2024 12:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5-nEJUbhO9J for <babel@ietfa.amsl.com>; Wed, 17 Apr 2024 12:24:47 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BF6C14F6FD for <babel@ietf.org>; Wed, 17 Apr 2024 12:24:44 -0700 (PDT)
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=1713381881; bh=DG2N/KYKqeYHaG6wRAx7M2iJReKUeBTBbV14x/UUexU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fAC/uryOUYQaz0OIxhbl+LAHMC7vEV9jHRkpnKoT1/0JEgmnZDj2V/wYmtwBJNT7u 4gP8V4dHSkKlr2zMLTS8rw0r4XW8KLmlVOUA3lVOk9zRHyojdwCWsCgPDtKz3iqP6J edfgxz0rSXCEZcp/IJiC8MfZxvZDntzfsiCL2sv+5HCDSeLTHe8Ip8L1MX1x8liCNs nSUYZZ6HFh02st9qXedqeZxoVtl2N1NU1JHLwfMEaEERJ881Dn3CnzCeoVr6pCDlNe LylNsywOKbeqYD4uRbL3HDW/ADydVn4QKxnAuqqLWc8Yf7fEdECIOvbcAGAPuDe2CL qHGO/J1NCHekA==
To: Juliusz Chroboczek <jch@irif.fr>
Cc: babel@ietf.org
In-Reply-To: <87sezki0w2.wl-jch@irif.fr>
References: <171328574275.28898.9111599332162642753@ietfa.amsl.com> <87v84h5k56.wl-jch@irif.fr> <87r0f5urqv.fsf@toke.dk> <87sezki0w2.wl-jch@irif.fr>
Date: Wed, 17 Apr 2024 21:24:41 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87y19bu70m.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/NUvlKApjqb27S9BR_12Oem4LQqI>
Subject: Re: [babel] New Version Notification for draft-ietf-babel-rtt-extension-06.txt
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 17 Apr 2024 19:24:53 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

>> The Bird implementation is compliant with section 3.2, although that may
>> change in favour of asking the kernel to timestamp incoming packets:
>> 
>> https://bird.network.cz/pipermail/bird-users/2024-April/017592.html
>> 
>> Using kernel (or hardware) timestamps is a better solution anyway, IMO,
>> so maybe that particular recommendation needs rethinking?
>
> Well, we want the timestamping to be consistent between implementations.
> I'm sure we can all agree that the procedure that's recommended by the
> document, while not optimal, is implementable on all systems.
>
> Timestamping in the kernel on Linux BIRD but not on other platforms means
> that we get different delay measures depending on the implementation,
> which I'm sure you'll agree is suboptimal.
>
> It won't matter much in practice, though, which is why the recommendation
> is just a SHOULD.

Well, the issue we're trying to resolve in Bird by using kernel
timestamps is that if the application blocks for a long time without
processing incoming packets, that will be part of the RTT which can (it
seems) lead to some pretty inflated RTT values.

If the implementation is *not* susceptible to such an issue (for
instance because it is multithreaded, say), then I agree that it won't
make much difference; in which case I don't know why we need the
recommendation in the first place.

But if the implementation *is* susceptible to such blocking issues, then
the robust recommendation would be to use kernel timestamping if it is
available. So, erm, maybe we should change it to that? Or drop this
entirely if we really believe that it doesn't make any difference?

>> We don't explicitly expire RTT state if the sanity checks keep failing,
>> so I don't believe we're compliant with the last paragraph of section
>> 3.3.
>
> I have misgivings about this paragraph myself.  Shall I remove it?

I'm not sure I understand the issue it is trying to solve, TBH; why was
it added?

-Toke