Re: [Raw] Some comments/questions on RAW Architecture

[Lou Berger <[e-mail]>]

Hi Pascal,

Please see below.

On 10/19/2022 12:34 PM, Pascal Thubert (pthubert) wrote:
> Hello Lou
>
> Many thanks for your comments!
>
>
>> Sure, I accept and didn't mean to question that the "RAW architecture" would be defined by "this document".
>> My question is more basic: what is the definition of RAW?
>> Said another way, what does RAW add to DetNet?
>> For example:
>> Does it change what services are supported - I don't think so
>> Does it define a new wireless technology - I don't think so
>> Does it define how detnet operates over wireless networks - I think so, this is what the charter says, but is this sufficient.
> We are in sync here
Great - of course this agreement on the document text is what we need to 
achieve.
>> I expected that this document would be the place which identified which aspects of wireless networks are being leveraged and abstracted to support DetNet.  Does this make sense?
> It does. We have introduced https://www.ietf.org/archive/id/draft-ietf-raw-architecture-07.html#name-raw-vs-upper-and-lower-laye with this goal in mind. We could list more aspects of wireless that are abstracted to L3, but I would not claim to be exhaustive, because forgetting something now would mean ignoring it in the future.
>
>> For example, I'd expect topics such as "Promiscuous Overhearing", "Partial Connectivity" (where not all endpoints are always reachable), "Changing Resource Availability", and the ability of the wireless layer to provide information to the routing layer (e.g., via DLEP)  to be identified as an important aspects.  Of course most of these topics are not really unique to wireless (consider the UNI/NNI/multi-layer work done for G.709) so the commonality and uniqueness should be called out.
>> This is the part I think is missing from the RAW definition.
> WFM, todo for me, to propose text along those lines before cut off.

In looking at the recently posted -09 version I see:

  On the other hand, the wireless medium provides
    unique capabilities that cannot be found on wires and that the RAW
    Architecture leverages opportunistically to improve the end-to-end
    reliability over a collection of links.

    Those capabilities include:

    Promiscuous Overhearing:  Because the medium is broadcast as opposed
       to physically point to point like a wire, more than one node in
       the forward direction of the packet may hear or overhear a
       transmission, and the reception by one may compensate the loss by
       another.  The concept of path can be revisited in favor multipoint
       to multipoint progress in the orward direction and statistical
       chances of successful reception of any of the transmissions by any
       of the receivers.

as previously discussed Promiscuous Overhearing is available in multiple 
technologies, e.g., ethernet multi and broadcast.  What is a bit 
different is that for some radio technologies you may have non-uniform 
multi/broadcast delivery. (Think about an ad-hoc wifi net where two 
endstations can hear a third end station, but not each other.)

    L2-aware routing:  As the quality and speed of a link variates over
       time, the concept of metric must also be revisited.  Shortest path
       loses its absolute value, and hop count turns into a bad idea as
       the link budget drops with the distance.  Routing over radio
       requires both 1) a new and more dynamic sense of the link, with
       new protocols such as DLEP and L2-trigger to maintain L3 up to
       date with the link quality and availability, and 2) a new approach
       to multipath routing, where non-equal cost multipath becomes the
       norm as shortest path loses its meaning with the instability of
       the metrics.

I think this ties in to my previous comment, where you a really talking 
about L2-aware *reachability* versus routing.

you also say:


    RAW distinguishes the longer time scale at which routes are computed
    from the the shorter forwarding time scale where per-packet decisions
    are made. RAW operates within the Network Plane at the forwarding
    time scale on one DetNet flow over a complex path delineated by a
    Track (see Section 2.3.2).

This is not at all unique to RAW - all IETF network technologies 
distinguish between routing (control-centric)  functions and forwarding 
(data-plane) functions.

     RAW operates within the Network Plane at the forwarding
    time scale on one DetNet flow over a complex path delineated by a
    Track (see Section 2.3.2).

a nit: saying RAW is limited to forwarding (data-plane) 
mechanisms/functions is inconsistent with the rest of the document.


>
>>> I answered that one separately. Bottom line is that a Track is the potential of any packet that is available at ingress and which usage is statistical whereas the path is the experience of one packet than can only be known when the packet is observed at arrival. The link between the two is the action of PREOF / PAREO all along the path, which can be a local decision based on the statistical shape of the potential next hop links. The text already covers that but I'd be happy to take suggestions that would help the reader understand this with more clarity.
>> I responded to that mail too, so will look to discuss the specifics there.
>> I do think this brings up the question of PAREO -- can a RAW network operate without protection or a different protection mechanism? (Keep in mind the DetNet architecture does *not* require PREOF, certainly the current specs do, but other mechanisms.)
> I believe that the current RAW work is all about optimizing the use of protection that is necessary to compensate for the unreliability that is inherent to wireless links. Compared to PREOF, PAREO has a richer panel and that' s good news because all this is much needed to achieve a reliable delivery.

IMO RAW should allow for protected and unprotected flows.

WRT tracks: I'm not sure we've made any progress on tracks vs protection 
paths. I see you have another message on this topic, so will respond to 
that message.

Thanks,

Lou

>
> Let me dig the other draft and answer that.
>
> All the best
>
> Pascal
>
>
>
> From: Lou Berger <[e-mail]>
> Sent: mercredi 28 septembre 2022 14:21
> To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> Cc: RAW WG <[e-mail]>
> Subject: Re: Some comments/questions on RAW Architecture
>
> Hi Pascal
> See below.
> ----------
> On September 16, 2022 11:31:31 AM "Pascal Thubert (pthubert)" mailto:[e-mail] wrote:
>> Hello Lou
>>
>> Starting again from your email on July 26th which forwards the original one, so you authored both > and >> below:
>>
>>    
>>> Hi Pascal,
>>>
>>> I don't think we ever really closed on the issues I raised below. Any chance
>>> you can summarize where you think we are on each of the points below - like
>>> you did for Balazs?
>>>
>>> Also some additional comments are in line below...
>>>
>>>
>>> On 3/20/2022 9:25 PM, Lou Berger wrote:
>>>> Pascal, Georgios,
>>>>
>>>> In looking to provide input on the framework document I realized I had
>>>> some basic questions on the architecture document. While I also have
>>>> more detailed comments/questions on the Architecture document, I'll
>>>> stick to the high level comments/questions here. Also, my apologies
>>>> for not getting them out sooner, but I figured it was still better to
>>>> document here than just "at the mic" in tomorrow's session.
>>>>
>>>> 1) What does the term "RAW" refer to in the context of the architecture?
>>>> Is it a new/standalone set of mechanisms or is it an addition or an
>>>> extension, or a usage of IETF defined technologies?
>>>>
>>>> I find that reading the architecture, I'm really  unsure.  The current
>>>> working is a bit mixed, e.g.,
>>>>
>>>>        Reliable and Available Wireless (RAW) provides for high reliability
>>>>        and availability for IP connectivity over a wireless medium.
>>>>
>>>> this sounds like something new/independent
>>>>
>>>>        It builds on the DetNet Architecture and
>>>>        discusses specific challenges and technology considerations needed to
>>>>        deliver DetNet service utilizing scheduled wireless segments and
>>>>        other media, e.g., frequency/time-sharing physical media resources
>>>>        with stochastic traffic.
>>>>
>>>> this sounds evolutionary.
>>>>
>>>> I was expecting the RAW WG to build on DetNet and other IETF Traffic
>>>> Engineering (TE)  bodies of work. In other works something along the
>>>> lines of:
>>>>
>>>>         The RAW Architecture builds on the DetNet Architecture and
>>>>         standard IETF Traffic Engineering concepts and mechanisms to
>>>>        deliver service across any combination of wired and wireless
>>>>        network segments. ...
>>>>
>>>> I think the document and the used terminology must be clear even we're
>>>> (understandably) loose in the usage of the "RAW" term in our discussions.
>> We discussed that at the last IETF RAW WG meeting. My understanding is that with RAW we mean what the architecture defines. So the "RAW architecture" would be synonymous to "this document".
>>
> Sure, I accept and didn't mean to question that the "RAW architecture" would be defined by "this document".
> My question is more basic: what is the definition of RAW?
> Said another way, what does RAW add to DetNet?
> For example:
> Does it change what services are supported - I don't think so
> Does it define a new wireless technology - I don't think so
> Does it define how detnet operates over wireless networks - I think so, this is what the charter says, but is this sufficient.
> I expected that this document would be the place which identified which aspects of wireless networks are being leveraged and abstracted to support DetNet.  Does this make sense?
> For example, I'd expect topics such as "Promiscuous Overhearing", "Partial Connectivity" (where not all endpoints are always reachable), "Changing Resource Availability", and the ability of the wireless layer to provide information to the routing layer (e.g., via DLEP)  to be identified as an important aspects.  Of course most of these topics are not really unique to wireless (consider the UNI/NNI/multi-layer work done for G.709) so the commonality and uniqueness should be called out.
> This is the part I think is missing from the RAW definition.
>>>> 2) Are RAW solutions limited to IPv6 and a limited set of wireless
>>>> technologies?  I think the framework says/implies no, but the
>>>> architecture is less inclusive. e.g.,
>>>>        RAW provides DetNet elements that are specialized for IPv6 flows
>>>>        [IPv6] over selected deterministic radios technologies [RAW-TECHNOS].
>>>>
>>>> I would expect that at least at the Architecture level that there
>>>> would be no exclusion of IETF networking technologies (including v4
>>>> and MPLS) and any SDO-defined wireless technology.  I certainly
>>>> understand needing to focus and prioritize work on specific
>>>> technologies, but that is practical choice not a limitation that
>>>> should be codified in the architecture.
>>>>
>>>> Somewhat related, but of less importance, it's probably worth
>>>> mentioning that RAW forwards/switches at the IP, not link layer.
>>>>
>>>>
>>> I think the abstract is a bit better, but the document remains confusing to
>>> me -- for example there's a new section title "RAW vs. DetNet" which again
>>> leads to the conclusion that a RAW enabled network is not a superset or
>>> compatible with a DetNet enabled network.  Perhaps changing the title of the
>>> section (s/vs/and) and adding a discussion of how a wired and wireless Detnet
>>> work with, or over, each other.
>>
>> Renamed to RAW and DetNet.
>>
>> Proposed addition:
>>    
>> "
>> RAW enhances DetNet to improve the
>>     protection against link errors such as transient flapping that are far more
>>     common in wireless links. Nevertheless, the RAW methods are for the most part
>>     applicable to wired links as well, e.g., when energy savings are desirable and
>>     the available path diversity exceeds 1+1 linear redundancy.
>> "
> I think this helps. Thank you.
>>
>>
>>> 3) How do tracks differ from TE protection paths?
>>>> In reading the definition of the tracks, the term seems quite
>>>> aligned/similar to TE protection paths and segments.  Keep in mind
>>>> that DetNet PREOF is just one form of service restoration supported in
>>>> IETF TE, i.e., the 1+1 form.  A track reads to me to be something that
>>>> can be composed or combine 1:1, 1:N and even 1+N, and have interesting
>>>> (uncoordinated) protection switching based on actual network/link
>>>> (channel) state.  I suspect we can accomplish the same objectives as
>>>> Tracks and stay consistent with existing DetNet and TE(AS) terminology.
>> I answered that one separately. Bottom line is that a Track is the potential of any packet that is available at ingress and which usage is statistical whereas the path is the experience of one packet than can only be known when the packet is observed at arrival. The link between the two is the action of PREOF / PAREO all along the path, which can be a local decision based on the statistical shape of the potential next hop links. The text already covers that but I'd be happy to take suggestions that would help the reader understand this with more clarity.
>>
> I responded to that mail too, so will look to discuss the specifics there.
> I do think this brings up the question of PAREO -- can a RAW network operate without protection or a different protection mechanism? (Keep in mind the DetNet architecture does *not* require PREOF, certainly the current specs do, but other mechanisms.)
>>>> 4) Is RAW limited to PCE-based centralized solutions?
>>>>
>>>> DetNet introduced the term Controller Plane to cover all types of
>>>> control supported by the IETF TE architecture, i.e., fully
>>>> centralized, fully distributed, or any hybrid combination of
>>>> centralized/distributed control.  The Architecture reads as supporting
>>>> only one combination of - PCE for paths, PSEs for tracks (aka
>>>> protection segments) .   PSEs read as also doing the actual protection
>>>> switching, but this is outside the scope of this comment.
>>>>
>>>> Hereto, I see no reason for the architecture to limit the scope of the
>>>> Controller Plan solutions that could be standardized as part of RAW.
>>>> (Yes PCE-based approaches are likely the first to be standardized, but
>>>> that's not an architecture level decision.)
>>>>
>>>>
>>>> Those are my top comments.  While substantive, I suspect addressing
>>>> these comments will result in some refactoring and rewording -- but
>>>> not a major change to the document.
>>>>
>>>> Thank you, and speak to you soon. (Unfortunately, just virtually this
>>>> meeting...)
>>>>
>>> I have some additional questions:
>>>
>>> Does the architecture allow for a Wireless DetNet operate without ARQ?
>>> Would it still be called a RAW network?
>> Yes and yes. ARQ is at most a hint that we pass to L2 which is free to translate that abstraction in its own terms.
>>
>> I added the following in the PAREO section:
>> "
>>       Because RAW may be leveraged on wired links, e.g., to save power, it is not
>>       expected that all lower layers support all RAW capabilities. Either way,
>>       RAW will manipulate the abstractions of the lower layer services and hint on
>>       the expected outcome, and the lower layer will act on those hints to provide
>>       the best approximation of the desired outcome, e.g., a level of reliability
>>       for one-hop transmission within a bounded budget.
>> "
>>
>> Please note that Georgios authored that section and I'd rather go by him for any major change.
> Okay, I'll wait for Georgio.
>>> What about a Wireless DetNet which operates over a radio technology that has
>>> built-in (sub-layer) ARQ - is this allowed? would it still be called a RAW
>>> network?
>> I suspect yes if DetNet has an abstraction for it. OTOH, if a plain DetNet stack operates over that medium but does not abstract the retries (e.g., in the form of a budget of bandwidth and latency) then tis becomes a hidden L2 property and this would not really be RAW. E.G., we can already do DetNet over TSN over 5G and that's not RAW.
>> RAW adds models and APIs for the PAREO functions,
> I think this is a very important point and one that should be one of the key points/topics in the architecture document. These APIs are very briefly mentioned in section 3.3 and as far as I can tell not represented in the figures.  Expanding and clarifying this would definitely help.
>> and the OODA loop that controls the use of the redundancy dynamically.
>>
> The use of an ooda loop in networking is nothing new and I personally find the focus on the term not helpful, but accept that this may be a style point.
>>> I think these points are not clear in the architecture document and should
>>> be.
>>>
>> I committed https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-architecture-07.txt so you can observe the proposed text, ready for more new text or fixes.
>>
> Thanks and I have reviewed the latest version in my comments.
> Thank you again for the discussion/responses.
> Lou
>> All the best, and many thanks again, Lou.
>>
>>
>>> Thanks!
>>> Lou
>>>
>>>> Lou
>>>>
>>>>