Re: [Raw] Proposed RAW charter

<David.Lake@Dell.com> Tue, 14 January 2020 17:10 UTC

Return-Path: <David.Lake@Dell.com>
X-Original-To: raw@ietfa.amsl.com
Delivered-To: raw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8023D120A9A for <raw@ietfa.amsl.com>; Tue, 14 Jan 2020 09:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ycKoY3qnJn1 for <raw@ietfa.amsl.com>; Tue, 14 Jan 2020 09:10:52 -0800 (PST)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8ABE120A12 for <raw@ietf.org>; Tue, 14 Jan 2020 09:10:52 -0800 (PST)
Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00EGtq1I003405 for <raw@ietf.org>; Tue, 14 Jan 2020 12:10:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=jeAiAFYFO5HYtDnStTiU345j8WPpW4NmlHsE3M99EZM=; b=rhzRCjlCVtD1/yxGp8sjR1ytKJ4Ml20sQBRi1jVUasVmaj0YnNmmKJAMogLFHHu5Y9il NEa0KugGK9yPNB2h3T1qddC5bZ6omlrwhv+1mBwAtO76e7dVOLC35NwP6SRIceQng7Kk gmbCz7R3DVBpUOeMYMiwpOea5SuK/pLjESUReHhj3YxSo7eG6c6sn8+P4FfaC3I3PGoA dkCg50Sqg0q8DAD7KfEXLPA+WV+RX11Wx8Rn4UwX8sdMIS5NLCPkSsGw0UMxwlaPQqvm Rh/YFS7kOeUFW8g31Vw74MhcF21W3qhccsUKJS+HmgXRa02VBdLuGKb3RVOsBinadFx0 ng==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2xfb30uqkv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <raw@ietf.org>; Tue, 14 Jan 2020 12:10:51 -0500
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00EGwLcN016467 for <raw@ietf.org>; Tue, 14 Jan 2020 12:10:51 -0500
Received: from ausxippc106.us.dell.com (AUSXIPPC106.us.dell.com [143.166.85.156]) by mx0b-00154901.pphosted.com with ESMTP id 2xhbewebjx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <raw@ietf.org>; Tue, 14 Jan 2020 12:10:50 -0500
X-LoopCount0: from 10.166.135.59
X-PREM-Routing: D-Outbound
X-IronPort-AV: E=Sophos;i="5.60,349,1549951200"; d="scan'208,217";a="509359525"
From: David.Lake@Dell.com
To: bebemaster@gmail.com, raw@ietf.org
CC: db3546@att.com
Thread-Topic: [Raw] Proposed RAW charter
Thread-Index: AdXKVnmbULuYyq59Tr2J+ZIiJo18pwAo8uqAAADSjQA=
Date: Tue, 14 Jan 2020 17:10:47 +0000
Message-ID: <015f01d5cafd$9043d980$b0cb8c80$@dell.com>
References: <F64C10EAA68C8044B33656FA214632C8AF87FBBE@MISOUT7MSGUSRDE.ITServices.sbc.com> <CA+-pDCfwfgF3p+qM1ge-uJANPMSR_=dC2U5ZC2bQw8aYpzWf-A@mail.gmail.com>
In-Reply-To: <CA+-pDCfwfgF3p+qM1ge-uJANPMSR_=dC2U5ZC2bQw8aYpzWf-A@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Microsoft Outlook 16.0
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [163.244.62.187]
Content-Type: multipart/alternative; boundary="_000_015f01d5cafd9043d980b0cb8c80dellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-14_04:2020-01-14, 2020-01-14 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 adultscore=0 bulkscore=0 malwarescore=0 suspectscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001140139
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 adultscore=0 clxscore=1011 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001140139
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/kafjyhsiRmQ3a4Opnp37-OFibos>
Subject: Re: [Raw] Proposed RAW charter
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: reliable and available wireless <raw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/raw>, <mailto:raw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/raw/>
List-Post: <mailto:raw@ietf.org>
List-Help: <mailto:raw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/raw>, <mailto:raw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2020 17:11:00 -0000

<DL> In-line </DL>

From: Raw <raw-bounces@ietf.org> On Behalf Of Justin Dean
Sent: 14 January 2020 16:47
To: raw@ietf.org
Cc: BRUNGARD, DEBORAH A <db3546@att.com>
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 <db3546@att.com<mailto:db3546@att.com>> 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
Raw@ietf.org<mailto:Raw@ietf.org>
https://www.ietf.org/mailman/listinfo/raw