Hello Brian
Many thanks for your review!
Please see below:
Le lun. 30 juin 2025 à 17:34, Brian Haberman via Datatracker <
noreply@xxxxxxxx> a écrit :
Document: draft-ietf-raw-architecture
Title: Reliable and Available Wireless Architecture
Reviewer: Brian Haberman
Review result: Ready with Nits
I am an assigned INT directorate reviewer for this draft. These comments were
written primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with any other
Last Call comments that have been received. For more details on the INT
Directorate, see https://datatracker.ietf.org/group/intdir/about/
I have reviewed this document from an Internet Area perspective. I believe this
document is ready for publication as an Informational document with some minor
edits.
1. Section 4.2 says "... performing the retries at Layer-3." I believe this
should be re-worded a bit to be specific about the retries being done in the
forwarding plane.
Is the below more clear?
"
RAW improves
the reliability of transmissions and the availability of the
communication resources, and should be seen as a dynamic optimization
of the use of redundancy to maintain it within certain boundaries.
For instance, ARQ, which provides 1-hop reliability through
acknowledgements and retries, and FEC codes such as turbo codes which
reduce the PER, are typically operated at Layer-2 and Layer-1
respectively. In both cases, redundant transmissions improve the
1-hop reliability at the expense of energy and latency, which are the
resources that RAW must control. In order to achieve its goals, RAW
may leverage the lower-layer operations by abstracting the concept
and providing hints to the lower layers on the desired outcome, e.g.,
in terms of reliability and timeliness, as opposed to performing the
actual operations at Layer-3.
"
2. I am curious about the over-emphasis on the OODA Loop concept. The document
spends an inordinate amount of time describing that framework and I think it
detracts a bit from the goal.
The term control loop is very vague and general for people without deep knowledge of control theory with typically a concept of feedback and adaptation. There's more to it in here.
The 4 steps of the OODA formalism match very well the steps we are taking in the RAW architecture. Additionally, OODA provides a starting point for the reader interested in digging more in control theory.
To your point, I removed some text about OODA but retained the mapping which, I believe, provides a structure for the reader to follow.
3. Another reviewer raised an issue with Figure 8 and I have to agree with
their assessment. The figure itself is a bit complex, but more importantly, the
supporting text never refers to the figure. I am not sure the figure is even
needed given the explanation provided in section 5.1.
Great point! I added proposed text to explain the figure:
"
Figure 8 illustrates a Network Plane recovery graph with links P-Q
and N-E flapping, possibly in a transient fashion due to a short-term
interferences, and possibly for a longer time, e.g., due to obstacles
between the sender and the receiver or hardware failures. In order
to maintain a received redundancy around a value of, say, 2, RAW may
leverage a higher ARQ on these hops if the overall latency permits
the extra delay, or enable alternate paths between ingress I and
egress E. For instance, RAW may enable protection path I ==> F ==> N
==> Q ==> M ==> R ==> E that routes around both issues and provides
some degree of spatial diversity with protection path I ==> A ==> B
==> C ==> D ==> E.
"
I reworked the looks as below.
Unsure we should remove it. Some people like text, some prefer a bit of illustration to support it.
+----------------+
| DetNet |
| Routing |
+----------------+
^
|
Slow
| Controller Plane
_-._-._-._-._-._-. | ._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-. | _-._-._-._-._-._-._-._-._-._-._-._-
| Network Plane
Expensive
|
__...--- | ----.._.
.( | )-._
( v ).
( A--------B---C----D )
_ - / \ / \ --._
( I---M--------N--***-- E -
-_ \ / / )
( P--***---Q----M---R .
_ )- ._
- <------ Fast -------> )
( -._ .-
(_.___.._____________.____.._ __-____)
*** = flapping at this time
4. I would also recommend considering some additional text in the document that
describes the potential conflict between the RAW control loop providing
reliability described in this document with control loops residing at the
transport layer doing similar functions. How will RAW avoid adversely
interacting with actions such as TCP retransmission?
You may ask the same question about DetNet in general.
Rerouting may affect the latency, but DetNet controls the end-to-end latency anyway,
Rerouting may also affect the packet ordering, but PREOF corrects that as well.
Both are inherited from DetNet, and are not specific to RAW.
You might also ask why ARQ (e.g., as present on Wi-Fi) is not an issue for TCP. Those exist whether DetNet is applied or not and there can be 50+ retries on the same frame. Typically, it's the order of magnitude of the involved delays that saves the day. I guess there could be transient side effects when DetNet is not used, but not with DetNet since the end-to-end latency is guaranteed and typically very stable.
The RAW control loop operates on the path but is not an end-to-end recovery mechanism.
Still, I completely agree with you, text was missing on the above.
Proposal: Add a first paragraph in section 4.2 just before the paragraph quoted above
"
4.2. RAW vs. Upper and Lower Layers
RAW builds on DetNet-provided features such as scheduling and shaping.
In particular, RAW inherits the DetNet guarantees on end-to-end latency,
which can be tuned to unsure that DetNet and RAW reliability mechanisms have
no side effect on upper layers, e.g., on transport-layer packet recovery.
RAW operations include possible rerouting, which in turn may affect
the ordering of a burst of packets. RAW also inherits PREOF from DetNet,
which can be used to reorder packets before delivery to the upper layers.
As a result, DetNet in general and RAW in particular offer a smoother
transport experience for the upper layers than the Internet at large
with ultra-low jitter and loss.
"
Works?
All the best,
Pascal
