Re: [Raw] Proposed RAW charter

["Prof. Diego Dujovne" <[e-mail]>]

All,
      For the time being, just a small comment:
I would like to define the charter about what it is going to be
made instead of what it is not (Solutions). I think it is nice to
see the right type of product we are looking for (are we looking
for Best Practices? Informational documents only? Define a
framework and/or an abstraction layer keeping relevant statistics
about the efficiency? are we looking for a model?)
Regards,

                     Diego Dujovne

Le mar. 14 janv. 2020 à 14:11, <[e-mail]> a écrit :

> <DL> In-line </DL>
>
>
>
> *From:* Raw <[e-mail]> *On Behalf Of *Justin Dean
> *Sent:* 14 January 2020 16:47
> *To:* [e-mail]
> *Cc:* BRUNGARD, DEBORAH A <[e-mail]>
> *Subject:* Re: [Raw] Proposed RAW charter
>
>
>
> [EXTERNAL EMAIL]
>
> Comments inline below.
> Justin Dean
>
>
>
> On Mon, Jan 13, 2020 at 2:14 PM BRUNGARD, DEBORAH A <[e-mail]>
> 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..
>
>
>
> This very first sentence seems off to me as later in the charter it's
> mentioned that no solutions are going to be directly in scope so will the
> work actually provide this or just outline the challenges and point towards
> solutions in DetNet/Manet/other WGs?  If no solutions will be in scope then
> I suggest leading with the next 1-2 sentences mixed with the first as way
> of introduction to RAW.
>
> The wireless medium presents significant challenges to achieve
> deterministic properties such as low packet error rate, bounded consecutive
> losses, and bounded latency. 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).
>
> and etc. is needed here unless this his is exhaustive.
>
>
>
> <DL> LDACS does not use IP.   A number of other systems where we need to
> create Reliable and Available Wireless paths do not use IP.   This limits
> the applicability of the technology.  Is it the PATH we wish to make
> Reliable and Available or the Protocol? </DL>
>
> 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.
>
>
>
> 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.
>
> (using wireless links?)
>
>
>
> <DL> “significant interest” reads purely of conjecture to me.  If what we
> are trying to do is to make the link Reliable and Available, does the
> higher-level protocol actually matter? </DL>
>
>
>
> 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.
>
> In terms of presentation of information the critical bit of info that RAW
> will NOT work on solutions seems a bit buried here and this should be moved
> towards the top.
>
>
>
> 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.
>
> Unnecessary suggest cutting previous sentence.
>
>
>
> 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.
>
> "these groups" meaning "these non-IETF groups"?
>
>
>
> <DL> The general concern I have is in terms of abstracting the Layer 1
> aspects from the delivery SLA.   The analogy I will draw where it works
> VERY well is VoLTE where the contract in terms of an IP QoS is explicitly
> tied to the air interface QCI and “reliability” is built by moving the
> voice call from a packet-switched to a circuit-switched connection if the
> air-interface breaks-down.   This means that the solution is anything BUT
> abstracted in terms of layers!
>
>
>
> We do need to be aware that significant, non-predictable behaviour can
> occur on RF connections – for example, the massive tropospheric “lift” that
> occurred across much of Western Europe at the end of December which caused
> OTA TV and Radio to be severely impacted for a number of days
> https://www.cambridge-news.co.uk/news/cambridge-news/freeview-tv-signal-down-people-17486405
>
>
>
> </DL>
>
> 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
>
>
>
>
>
> --
> Raw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw
>
> --
> Raw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125