[Raw] Martin Duke's Abstain on draft-ietf-raw-use-cases-08: (with COMMENT)
Martin Duke via Datatracker <noreply@ietf.org> Wed, 30 November 2022 18:18 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: raw@ietf.org
Delivered-To: raw@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D93C1524C2; Wed, 30 Nov 2022 10:18:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-raw-use-cases@ietf.org, raw-chairs@ietf.org, raw@ietf.org, corinna.schmitt@unibw.de, corinna.schmitt@unibw.de
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <166983230472.65207.7463914779013001117@ietfa.amsl.com>
Date: Wed, 30 Nov 2022 10:18:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/jK2kRUrFU_g8jQYR1Kl3tYzw68U>
Subject: [Raw] Martin Duke's Abstain on draft-ietf-raw-use-cases-08: (with COMMENT)
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.39
List-Id: reliable and available wireless <raw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/raw>, <mailto:raw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/raw/>
List-Post: <mailto:raw@ietf.org>
List-Help: <mailto:raw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/raw>, <mailto:raw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2022 18:18:24 -0000
Martin Duke has entered the following ballot position for draft-ietf-raw-use-cases-08: Abstain 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-raw-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I see no flaws in this Informational document that rise to the level of a DISCUSS, but its current form I don't think it is a particularly useful contribution to the RFC series. It would need a major revision to reach that level, in my opinion. Broadly speaking, the document describes a number of wireless use cases, but doesn't create a unified framework of requirements associated with them, certainly doesn't make the case that a detnet-style solution is appropriate. Here is a non-exhaustive list of examples: (2.3) "It is necessary to keep latency, time and data overhead of new aeronautical datalinks at a minimum." 'At a minimum' is not a real requirement: these things are always traded off against other design considerations. A completely integrated, bespoke protocol stack with custom hardware all along the path is always the way to get "minimum" latency, but this is impossible in practice. Instead, there should be a number attached to the metric, or at least "similar latency to interactive voice", or whatever. (3.4) "The network infrastructure must support heterogeneous traffic, with very different critical requirements. Thus, flow isolation must be provided." Individual identification of flows doesn't follow at all. The whole concept of Diffserv is to provide differentiated services without identifying individual flows. (6.4.1) "But note that in most of these scenarios, part of the communication path is not wireless and DetNet mechanisms cannot be applied easily (e.g., when the public Internet is involved), and therefore in these cases, reliability is the critical requirement." If I read this correctly, it's saying "low latency would be nice but we can't actually guarantee it". Reliability without hard latency bounds already has a solution: TCP. (8.4) "When a given service is decomposed into functions -- hosted at different robots -- chained, each link connecting two given functions would have a well-defined set of requirements (latency, bandwidth and jitter) that must be met." For this use case, you throw up your hands and say "requirements depend on the application," which is the most banal statement possible. This is indicative of the problem that this use case document is identifying market segments rather than technical requirements that will drive the work. As it stands, this use case provides zero motivation for RAW rather than existing protocol solutions. (9.4) "The inter-network needs to operate in damaged state (e.g. during an earthquake aftermath, heavy weather, wildfire, etc.). In addition to continuity of operations, rapid restore is a needed characteristic." Robustness to infrastructure damage is one of the original design requirements of the Internet, and does not motivate new work. ... and so on. A much better approach to this document would articulate specific requirements levied on the network that are not well served by existing standards, and then tie those shortfalls into specific use cases.
- [Raw] Martin Duke's Abstain on draft-ietf-raw-use… Martin Duke via Datatracker
- Re: [Raw] Martin Duke's Abstain on draft-ietf-raw… CARLOS JESUS BERNARDOS CANO