Re: [manet] Fwd: [Raw] Proposed RAW charter

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Rex,

Some of the answers really belong to Deborah who carefully crafted the current text with a lot of simplification from the original. It’s good to know if we went too far...

Please see below:

> Le 14 janv. 2020 à 03:09, Rex Buddenberg <[e-mail]> a écrit :
> 
> Comments in line.
> 
>> On Mon, 2020-01-13 at 15:23 -0800, Alvaro Retana wrote:
>> FYI…
>> 
>> Bellow is a proposed charter for RAW.  As you can see, it
>> specifically calls DLEP and the manet WG out.
>> 
>> Please take a look and, as possible, contribute to the definition of
>> the charter and the work to be done.
>> 
>> Thanks!
>> 
>> Alvaro.
>> 
>>> On January 13, 2020 at 4:14:59 PM, BRUNGARD, DEBORAH A ([e-mail]
>>> m) wrote:
>>> Hi RAW,
>>>  
>>> Happy New Year!
>>>  
>>> As promised, here’s a proposed charter. Please send comments. I’ll
>>> be submitting it to the IESG for the first step (internal review)
>>> by the end of the week.
>>>  
>>> Note, while the BoF had the most support for doing only use cases
>>> and requirements, I’ve included here also a gap analysis and an
>>> architecture/framework document. I think the gap analysis will be
>>> the most critical. The architecture/framework is intended not to be
>>> the typical comprehensive protocol architecture, but only
>>> architectural aspects of what is needed to enable deployment and
>>> usage in a wireless network.
>>>  
>>> Looking forward to your comments-
>>> Deborah
>>> (your supporting AD)
>>>  
>>> --
>>>  
>>> Reliable and Available Wireless (RAW) provides for high reliability
>>> and availability for IP connectivity over a wireless medium... 
> 
> I'd imagine that most internetworks would have wireless segments in
> them but would not be exclusively wireless.  The way this is stated,
> you imply all-wireless.  We have two topologies to deal with:
>   - the 'conventional' one with the wireless at the edge (last router-
> end system LAN problem).  The rest of the internetwork is wired.
>   - the less conventional one where there is a radio-WAN (meaning
> router-router) wireless segment in the interior or the internetwork.
> (contention MACs don't work here.  

Well, there’s also the quite conventional wireless mesh (e.g., fixed Wi-Fi or 6TiSCH) which is in scope.

> 
> 
>>> The wireless medium presents significant challenges to achieve
>>> deterministic properties such as low packet error rate, bounded
>>> consecutive losses, and bounded latency. 
> 
> While this is true, these are qos issues, not reliability/availability
> ones. What are we after? I think there is a case for high availability
> engineering, but wrapping yourself up on qos issues is not the way to
> get at it.

My view:

RAW focuses on compensating for transmission losses which is where it differs from DetNet. It will use the larger paraphernalia that wireless enables, e.g., overhearing.

Packet error rate (due to transmission errors) is reliability. Losses in a row relates to downtime and thus availability. 

QoS would manage congestion loss (xmit queue saturated) and that’s the piece we inherit from DetNet (with bounded latency for use cases that require it).



> 
>>> RAW extends the DetNet Working Group concepts to provide for high
>>> reliability and availability for an IP network utilizing scheduled
>>> wireless segments and other media, e.g., frequency/time-sharing
>>> physical media resources with stochastic traffic: IEEE Std.
>>> 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable 
>>> low latency communications (URLLC), IEEE 802.11ax/be, and L-band
>>> Digital Aeronautical Communications System (LDACS). Similar to
>>> DetNet, RAW will stay abstract to the radio layers underneath,
>>> addressing the Layer 3 aspects in support of applications requiring
>>> high reliability and availability.
> 
> This is a catalog of prospective solutions, not a statement of
> requirements. Or, restated, the prospective solutions ... but to what
> problem?

Not solutions but underneath technologies we will work with.

We had more text on that earlier. There’s a tension between exhaustive and simple... I leave this to Deborah.

> 
>>>  
>>> While DetNet solutions apply to both wireless and wired, there has
>>> been recent industry interest for wireless applications which were
>>> not initially included in the DetNet use cases. One critical
>>> application is Aeronautical Data Communications. The Aeronautical
>>> standards work on a physical layer and data link layer for data
>>> communications is reaching maturity and there is significant
>>> interest in developing an IP connectivity solution.
> 
> I think there is an automotive application that is as compelling. In
> both cases, emergency vehicles should be highlighted in the use cases
> and requirements statements as they tend to represent the 'tall pole in
> the tent'.  Meet the requirements for an instrumented ambulance and
> you'll exceed most others.  
> 

Yes the charter insists a lot on one use case.

The use cases draft has many more but not the above. Your contribution would be welcome!



> In both cases a mature view of the topology is necessary: you're using
> the wireless to reach to a LAN inside the vehicle.  That is, the
> vehicle is not an end system but a transport of one or more network
> segments.  Therefore the wireless segment of concern is a router-router 
> segment of an internetwork -- in the interior, not at the edge.  
> 
>>>  
>>> In the interests of providing timely solutions for these newly
>>> identified industry applications, RAW’s focus will be on
>>> identifying use cases and requirements for these new applications.
>>> RAW will solicit input on deployment plans, requirements, and
>>> operational practices (including security and privacy aspects) for
>>> these newer industrial applications. RAW’s primary focus is on
>>> identifying areas where the DetNet adaptation to wireless networks
>>> requires additional supporting mechanisms. The RAW Working Group
>>> will also examine the applicability of other existing IETF work,
>>> e.g..., DLEP.  The RAW Working Group will provide input to the
>>> DetNet Working Group, MANET Working Group, and other IETF Working
>>> Groups, and cooperate in reviewing solutions to RAW’s identified
>>> deployment problems. RAW is not chartered to work on a solution, if
>>> solution work is needed in addition to the DetNet solution work or
>>> other existing solution work in the IETF, it will be coordinated on
>>> where the work will be done.
> 
> I'm confused.  In the first sentence the WG is to provide timely
> solutions.  But the last sentence says something a bit different. ??
> 
> In the military's world, we have two flavors of such documents; Mil
> Standards and Mil Handbooks. Engineering coaching and best practices
> generally are found in the latter.  
>>>  
>>> The RAW Working Group is planned to be a short timeframe (12-18
>>> months) Working Group to quickly address these newer industry
>>> applications. The initial milestones will be comprised of
>>> Informational documents. The documents may exist individually or on
>>> a git repository. The use case document may consist of one or more
>>> documents to allow users/operators the opportunity to provide
>>> comprehensive deployment plans for these new (to IETF)
>>> technologies. The group will closely coordinate with the DetNet and
>>> MANET Working Groups. The work produced by this group may be of
>>> interest to other SDOs, 3GPP, IEEE, and the Aeronautical industry.
>>> No formal co-ordination is anticipated with these groups at this
>>> time.
> 
> 
> 
>>> Milestones
>>> Draft for “Use Cases” adopted by WG
>>> Draft for “Problem Statement and Requirements” adopted by WG
>>> Draft for “Architectural/Framework aspects to enable deployment and
>>> usage in a wireless network” adopted by WG
>>> Draft for “Evaluation of Existing IETF Tools and Gap Analysis”
>>> adopted by WG
>>> Draft for “Use Cases” submit for publication
>>> Draft for “Problem Statement and Requirements” submit for
>>> publication
>>> Draft for “Architectural/Framework aspects to enable deployment and
>>> usage in a wireless network” submit for publication
>>> Draft for “Evaluation of Existing IETF Tools and Gap Analysis”
>>> submit for publication
>>>  
> 
> I don't see below where we're supposed to recite the definitions and
> principles that are central to high availability internetworks.  You
> need these.....

There’s text in the problem statement draft already. Could you have a look?


> 
> Definition. Availability is defined as up-time/total-time.  With a bit of algebra that can be restated as (total-time - down-time)/total-time. It's usually easier to identify tolerable down-time in the analysis. 
>    In my experience the hardest part of the problem is to get the sponsor to state the Ao requirements. I've seen several programs of this ilk that made no availability requirement statement at all. 
> 
> Principles.  There are three principles of high availability engineering:
>  - elimination of single points of failure (e.g. by provisioning of alternate network segments)
>  - reliable crossover from primary to backup (IP does this by design)
>  - prompt notification of failures as they occur (part of the management function, fault management)
> 

All good contribution to the problem statement!

All the best,

Pascal 


> 
> 
> b
> 
> 
>>>  
>>> -- 
>>> Raw mailing list 
>>> [e-mail] 
>>> https://www.ietf.org/mailman/listinfo/raw 
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet