[Raw] Martin Duke's Abstain on draft-ietf-raw-use-cases-08: (with COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

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.