[Detnet] Re: draft-ietf-raw-architecture-25 telechat Intdir review

[Brian Haberman <[e-mail]>]

Thanks, Pascal.

Your responses make sense to me.

Regards,
Brian

> On Jul 7, 2025, at 5:15 AM, Pascal Thubert <[e-mail]> wrote:
> 
> Hello Brian
> 
> Many thanks for your review!
> 
> I placed the candidate changes in GitHub at https://github.com/raw-wg/raw-architecture/commit/53da0fa3396ba7bfb14a85779ccbe67d5ed7de4a
> 
> Please see below:
> 
> Le lun. 30 juin 2025 à 17:34, Brian Haberman via Datatracker <[e-mail] <mailto:[e-mail]>> 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.
> 
> You might also ask why use TCP over DetNet. Strange idea indeed, see draft-thubert-tsvwg-detnet-transport-01 <https://datatracker.ietf.org/doc/html/draft-thubert-tsvwg-detnet-transport-01>
> 
> 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