[babel] Zaheduzzaman Sarker's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)
Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> Wed, 14 February 2024 01:26 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: babel@ietf.org
Delivered-To: babel@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C345EC14F5FB; Tue, 13 Feb 2024 17:26:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Zaheduzzaman Sarker via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-babel-rtt-extension@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, d3e3e3@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Message-ID: <170787401277.9987.12424865727760301020@ietfa.amsl.com>
Date: Tue, 13 Feb 2024 17:26:52 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/hoNmEWLWWBjXlkG-v0YnqVojSmk>
Subject: [babel] Zaheduzzaman Sarker's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.39
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, 14 Feb 2024 01:26:52 -0000
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-babel-rtt-extension-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rtt-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for working on this specification. It seems like a oversight from us that it didn't get any TSVART review at the earlier stage of this document. I have following issues to discuss - # I support Rob's discuss that it is not clear why this is published as standard track document. Apart from what Rob pointed out, there is another place where the experimental nature of this specification is obvious. In section 1 it says - "We believe that this protocol may be useful in other situations than the one described above, such as when running Babel in a congested wireless mesh network or over a complex link layer that performs its own routing; the fine granularity of the timestamps used (1µs) should make it possible to experiment with RTT-based metrics on this kind of link layers." This shows lack of confidence on the results and request for more experiments. As RTT-based route selection can end up having negative impacts by overloading and congesting low RTT routes, we must run enough experiments and have enough data to declare it safe for the Internet. I am lacking the those information. # This specification does not specify the relation to other loss-based metric and hop-count metric based strategies. I can imagine a network where low RTT can be emitted at the cost of packet loss. Will this RTT-based strategy be safe to use? # How would this RTT-based strategy will co-exists with other strategies those are deployed already as claimed in this specification? This specification need to guide the implementers about what to consider when selecting the routing strategy and how the strategies can co-exits. # The periodicity of HELLO message is not clear to me. This is an important piece of information that should be derived from proper experiments as we don't want the HELLO message to overload the route or path. The discussion on when to stop sending those HEllO messages is required. Also the frequency of the HELLO message might help adjusting the clock drift, as it is an important aspect of the accuracy of the algorithm. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I was also wondering how does A calculate the RTT towards D via B and C? does it only computes the RTT between itself and B and compares with that with C, or does it some how knows the whole end to end RTT? this part is also under specified or I have certainly missed it.
- [babel] Zaheduzzaman Sarker's Discuss on draft-ie… Zaheduzzaman Sarker via Datatracker
- Re: [babel] Zaheduzzaman Sarker's Discuss on draf… David Schinazi
- Re: [babel] Zaheduzzaman Sarker's Discuss on draf… Juliusz Chroboczek
- Re: [babel] Zaheduzzaman Sarker's Discuss on draf… Zaheduzzaman Sarker
- Re: [babel] Zaheduzzaman Sarker's Discuss on draf… Zaheduzzaman Sarker
- Re: [babel] Zaheduzzaman Sarker's Discuss on draf… Gunter van de Velde (Nokia)