Re: [Raw] Thoughts on Problem Statement draft: gaming

"Grossman, Ethan A." <eagros@dolby.com> Wed, 23 October 2019 20:07 UTC

Return-Path: <eagros@dolby.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 7D7CB1208A0 for <raw@ietfa.amsl.com>; Wed, 23 Oct 2019 13:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.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 JGeCFySLgov1 for <raw@ietfa.amsl.com>; Wed, 23 Oct 2019 13:07:07 -0700 (PDT)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720112.outbound.protection.outlook.com [40.107.72.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A3B120129 for <raw@ietf.org>; Wed, 23 Oct 2019 13:07:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NZBR8DuSXrZyGBckzAgxPE5Bl5NYk4f5v1d8L0L4IRN+tvb95jkdw5lthZ/9BeQT969PibXvkQNb3T7MGucYzxB3YK8cevVs66ShN3qdQyoxRwtbZfyc9v7T2L9koYGRrTTFphZiFvXodsJFDhvMINagCeUnE2/ToejxwGknszQPHaWiFEWukRH4irLYW1xunVTZbLz/qRvJiYQIYAf/6yRFFQc2l4p2JaxpaQHLsj081C+ecVDdgwC9U9drHlNWn8HNTswwaumcM/zDHefCvdbYtVdIzMDl3bHtWMsp69BmtaRRE+NEQHTnMEeQelibCt6S9RvOY97bzKRMGjYtaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qyiEzO0l1UbUUUJGA5X4wuiNCVzRIKlZNtROLIVrqSw=; b=ArC2lI60f8lNd+1pqpq8z/TNbqrVsLVNX2ep0Di6eQR4X7wbJYwC/ohhm4lgFSTfAW+wOUl+NpisFNhrMEI8apOlROF5bU/tRejjhytbzm1xyr531NrFely23bfdncWvzDY6Eta2uk9cIUvOxyWpHwOpRchVIlXKGZlwayyBhHGSVgXnVE5GBWEfXGVrJQItAE6GHYqMiTpm93jwek1Aqyl8pDnPxOM2A3sMiyxUCMVzGZPjkKph8+xiJoL42zZDlalF1bvb5RAcQHbma14QsDwCX9itf8To0d1X1KNCiGXjykyWUQn9tYTmCuIScIlBfZMIwlzhtMXCLi2Ype4gPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dolby.com; dmarc=pass action=none header.from=dolby.com; dkim=pass header.d=dolby.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qyiEzO0l1UbUUUJGA5X4wuiNCVzRIKlZNtROLIVrqSw=; b=fvvT9iJBRZoqP5/KHRG9rCacKHmZA8tPVGhgo1UIj7L0UaGTxPOAV6PVde5C8OQVSCghTsudEilx/tFYYxVgZJm7oMD6Ph3Bv2tupQgzZMauYB1IUL0DM8xYhexhOyzVAt48mZnN1TBJSF8X1NaQjvXaQ+kV+DsSvZflwpsWtgs=
Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB6357.namprd06.prod.outlook.com (20.178.51.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.20; Wed, 23 Oct 2019 20:07:04 +0000
Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::4133:d57b:b32e:99b8]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::4133:d57b:b32e:99b8%3]) with mapi id 15.20.2347.030; Wed, 23 Oct 2019 20:07:04 +0000
From: "Grossman, Ethan A." <eagros@dolby.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
CC: "raw@ietf.org" <raw@ietf.org>
Thread-Topic: [Raw] Thoughts on Problem Statement draft: gaming
Thread-Index: AQHViJ5a0grUOmBiyEKSyCgBuaMzdqdmOs5AgAAD+YCAAKpbAIAABWqAgAD6qICAALuCsA==
Date: Wed, 23 Oct 2019 20:07:03 +0000
Message-ID: <BYAPR06MB4325B30CB44E03FFA1BC33A5C46B0@BYAPR06MB4325.namprd06.prod.outlook.com>
References: <BYAPR06MB432572B2D1AAE15FDB0AA2AFC4680@BYAPR06MB4325.namprd06.prod.outlook.com> <D85D6B70-5777-40A8-89CD-353BF1578C82@cisco.com> <BYAPR06MB4325B7F3BA0E1B330CDA8840C4680@BYAPR06MB4325.namprd06.prod.outlook.com> <CALypLp_BtEpjKJy5hsroSKe7-nr7rdbsAXKpci+WMtuRKESTgw@mail.gmail.com> <BYAPR06MB43257C7A0DC1E85B82D22178C4680@BYAPR06MB4325.namprd06.prod.outlook.com> <CALypLp8XvRo39aA4v5jKCoo3-pwLYrHxktwiQbVVg27nE5-JNg@mail.gmail.com> <MN2PR11MB35656631C7959B5174E414A1D86B0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35656631C7959B5174E414A1D86B0@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWFkMjFiNzMwLWY1ZDAtMTFlOS1iOTBmLTg0ZmRkMTNjZDRjZlxhbWUtdGVzdFxhZDIxYjczMi1mNWQwLTExZTktYjkwZi04NGZkZDEzY2Q0Y2Zib2R5Lmh0bWwiIHN6PSIyODc1MiIgdD0iMTMyMTYzMzQ4MjI5NzQzODUwIiBoPSJqSjlvU21Edk1VbUc2ci9zTXBBL0xwK1lSM009IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+
x-dg-rorf:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com;
x-originating-ip: [8.39.141.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3ab7395c-6a87-4fec-fbc6-08d757f492b3
x-ms-traffictypediagnostic: BYAPR06MB6357:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <BYAPR06MB635777B62A1FDBE62E85A98DC46B0@BYAPR06MB6357.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 019919A9E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(136003)(346002)(396003)(199004)(189003)(43544003)(14444005)(102836004)(66446008)(6436002)(446003)(64756008)(606006)(86362001)(5070765005)(55016002)(8936002)(476003)(52536014)(486006)(66556008)(6246003)(8676002)(186003)(3846002)(790700001)(66946007)(66476007)(54896002)(30864003)(76176011)(6306002)(14454004)(966005)(229853002)(110136005)(99286004)(6116002)(9686003)(316002)(66574012)(7736002)(81156014)(2906002)(236005)(11346002)(74316002)(33656002)(76116006)(71200400001)(5660300002)(256004)(71190400001)(7696005)(81166006)(66066001)(6506007)(26005)(53546011)(4326008)(25786009)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB6357; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:3;
received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RS9P+LSfNNVmy+ocs06xTHMDyll+MnYLRMeRoiOOVqSS9MSza8ByAsHUXXpZkrS6o4IXKrwU9/en/+7DoJFbt6j8k3BtHsELVE06/aPYFGfMWU0zc3dEdLpQU8XaEM2fEskiplF6ziiNZORZ6uWoUJhx+4jVhG5C4lmkNSNG2wC/TaywRKVdr76LSWYwf2hOPlXe9+n+RPBsRg160LjbP4MqtVRgx9Oer+luLK3F2tHiWtFZc7hC9/Ym0mTwd85Me/v1le+u2UDhAJ5eLy0sFz6j70/r3TCYlSyDzH8m+g/v/l2e+u8dDIHkDKFAGf7bDNKO8kP9XHWVQxJ222I9Gh0l0TStNHpVsNH6Qk+kyyLZeTZ9JZeiPMwLMLCqFSdj9Fqkc0BMh9bOy4VD21KSBDB7S7nGfxM2jr73SWTvtmdTwmmLXsaaxJaVg2/JKR+5COcASi1Xq/OiKSufH34FmxjHLiC7NMNdU8WtWJyPbqY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR06MB4325B30CB44E03FFA1BC33A5C46B0BYAPR06MB4325namp_"
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ab7395c-6a87-4fec-fbc6-08d757f492b3
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2019 20:07:04.0220 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: E6CbfDEbhCpSGljugAqRZ3I/Pm09HzI9n80ziiWmBW2YUtzKw4eDkEyWV1/Q1nxXiqB36f8yO2Fx+O3hlZU5mQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB6357
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/QMybEEcO-UCguxRAGZwOQQYBBio>
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming
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: Wed, 23 Oct 2019 20:07:13 -0000

I understand that “gaming” is an important use case for RAW, specifically for WiFi, so we don’t want to “lose” that use case. And that the requirements may not overlap entirely with DetNet, so as long as we make that clear, we can keep it, no problem.

Ironically WiFi is also the only meaningful use case for Pro Audio/Video, since (as I understand it last I read it) none of the other protocols named have sufficient bandwidth. So, gaming is not the “only” RAW use case for WiFi.

And, I am now thinking that since (as I understand it) WiFi does not depend on real-time per-packet routing (as e.g. 6TiSCH uses), then perhaps WiFi is a kind of degenerate case of RAW? In other words, if we just consider “what is RAW for WiFi” by itself, what do we have?

In other words, what work would RAW have to do to support only WiFi, given that WiFi itself has been enhanced to support some measure of bounded latency, even if that can’t be guaranteed in the case where the shared airspace is compromised by outside forces? (We will assume that for purposes of our use cases that the user is responsible for protecting the shared airspace). (Note that at the time the DetNet Use Cases were written, WiFi did not have bounded latency, but I gather it has now been implemented, or is in the process).

As another example, consider one of the industrial wireless use cases for DetNet which is “rotating machines for which wired connections are impractical” – in that case we can assume that the shared airspace in the factory setting is guaranteed to be clear, and all we care about is the performance of the devices involved in the communication.

I don’t know the answer to this, I am asking it as a pure question…
Ethan.

From: Pascal Thubert (pthubert) <pthubert@cisco.com>
Sent: Wednesday, October 23, 2019 1:38 AM
To: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>es>; Grossman, Ethan A. <eagros@dolby.com>
Cc: raw@ietf.org
Subject: RE: [Raw] Thoughts on Problem Statement draft: gaming

Please do not hurry too much.

Let’s discuss that at the call Friday and at the BoF. I’m unclear that we are fully a subset of DetNet. And it’s not clear hat the reasons why DetNet does do gaming applies to RAW. Wireless Gaming is a core requirement for IEEE 802.11 and it should be propagated over IP even if it cannot be made ‘deterministic’. Maybe reliable and available over redundant 5G and WiFi6 access is good enough for gaming, and best can do for an erratic bandwidth requirement.

All the best

Pascal

From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es<mailto:cjbc@it.uc3m.es>>
Sent: mardi 22 octobre 2019 19:41
To: Grossman, Ethan A. <eagros@dolby.com<mailto:eagros@dolby.com>>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; raw@ietf.org<mailto:raw@ietf.org>
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

OK, I'll do that.

Carlos

On Tue, Oct 22, 2019 at 7:22 PM Grossman, Ethan A. <eagros@dolby.com<mailto:eagros@dolby.com>> wrote:
Hi Carlos,
Yes, if you want RAW to be congruent with DetNet then you should expunge any possible reference to Internet-based gaming (or anything else Internet…).
Thanks,
Ethan.

From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es<mailto:cjbc@it.uc3m.es>>
Sent: Tuesday, October 22, 2019 12:12 AM
To: Grossman, Ethan A. <eagros@dolby.com<mailto:eagros@dolby.com>>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; raw@ietf.org<mailto:raw@ietf.org>
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

Hi Ethan, Pascal,

The use case described in the use-cases draft was intended to be generic, so it describes the Internet gaming with a special focus on the wireless part. If you believe it is clearer to rename it to wireless gaming and to rewrite it a bit so the focus is 100% crystal clear, we can do that.

My two cents,

Carlos

On Tue, Oct 22, 2019 at 8:59 AM Grossman, Ethan A. <eagros@dolby.com<mailto:eagros@dolby.com>> wrote:
Just that as described in the DetNet use case given (and deemed unsupported), it was Internet-based. That’s it. If it clearly isn’t that, then no problem.
Ethan.

From: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Sent: Monday, October 21, 2019 11:03 PM
To: Grossman, Ethan A. <eagros@dolby.com<mailto:eagros@dolby.com>>
Cc: raw@ietf.org<mailto:raw@ietf.org>
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

Hello Ethan

I missed the conversation on gaming at DetNet;  but RAW might not be a perfect subset of DetNet and gaming was a core requirement for 802.11 RTA.

Would you have more on why DetNet would not have it?
Take care,

Pascal

Le 22 oct. 2019 à 04:43, Grossman, Ethan A. <eagros@dolby.com<mailto:eagros@dolby.com>> a écrit :

Hi Pascal et al,
As I am reading through this draft here are my thoughts:


  1.  “provide a Reliable and Available service” – I don’t think this is a clearly defined term, particularly when capitalized as a proper name. In lower case each word could be parsed for a definition (“reliability” and “availability” each have definitions in this context, I would say, e.g. https://reliabilityweb.com/tips/article/understanding_the_difference_between_reliability_and_availability/<https://urldefense.proofpoint.com/v2/url?u=https-3A__reliabilityweb.com_tips_article_understanding-5Fthe-5Fdifference-5Fbetween-5Freliability-5Fand-5Favailability_&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=s6yG2meL6NSsvmY66p01BSmIkKPQ07RWSVIXMFRWHRo&s=vUnJ3E-S5ijRAzUE9-I2Uas8goTa_nrxoI1ssy9-L_g&e=>)oTa_nrxoI1ssy9-L_g&e=>). I think early in the draft we should carefully define what RAW means in practice, and how it differs from “deterministic”, the word we are trying to avoid. Perhaps this definition could be based on the sentence from section 4: “[A] prerequisite is that an IP link can be established over the radio with some guarantees in terms of service reliability, e.g., it can be relied upon to transmit a packet within a bounded latency and provides a guaranteed BER/PDR outside rare but existing transient outage windows that can last from split seconds to minutes.”
  2.  “getting traction in various industries including .. online gaming… “. Online gaming is explicitly out of scope for DetNet so even if it has some possible relevance it will just raise the wrong questions, please delete. I see that there is a reference to gaming at https://tools.ietf.org/html/draft-bernardos-raw-use-cases-00#page-10<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbernardos-2Draw-2Duse-2Dcases-2D00-23page-2D10&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=s6yG2meL6NSsvmY66p01BSmIkKPQ07RWSVIXMFRWHRo&s=WAHEAfxOqBBbkM8-TyoreUuj1Rgqu7Ou25AYTGKy2ns&e=>1Rgqu7Ou25AYTGKy2ns&e=>, and there the variants appear to be differentiated from “online” (which I interpret to mean Internet-based) gaming. Maybe one could say “wireless gaming”, although in the interest of cleanliness I would rather drop it entirely for the Problem Statement.
  3.  “as a first approximation can ignore flapping” – is the meaning of “flapping” really understood outside the wireless community?
  4.   “This signaling enables relays to tune retries and replication to be met” – Somehow this sentence doesn’t converge for me –  maybe you are trying to say “This signaling enables relays to tune retries and replication to meet the required QoS”?
  5.  Can Informative RFC/drafts be referenced Normatively as done here with the DetNet and RAW Use Case drafts?
  6.  It seems DLEP is rather close to what RAW needs, but extended (presumably by an independent layer/protocol) to include a more dynamic and interactive parameterization of the link? I would like to hear in a little more detail how DLEP could fit in with RAW.
  7.  Perhaps a diagram of how RAW would fit in with DetNet would be helpful? Like what would be the analogous diagram to https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddetnet-2Dip-2Dover-2Dmpls-2D02&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=s6yG2meL6NSsvmY66p01BSmIkKPQ07RWSVIXMFRWHRo&s=LZQ1i4J_bjDHNEt5b7WdlS59W4sBWOqzAbEWksFdRHk&e=>W4sBWOqzAbEWksFdRHk&e=>, figure 1? I feel like I can see what RAW is trying to do, i.e. enable per-packet path decisions, but I don’t quite see how that interface to DetNet would work, e.g. from a layering standpoint. Of course, this may all be perfectly obvious to one skilled in the art, but sadly I am not. Looking forward to item #14 below, perhaps we would be replacing the Forwarding plane shown in [the above mentioned ip-over-mpls figure] with the “RAW Forwarding plane”? If so, then what else would have to change in that diagram?
  8.  Is the result to be a draft like “detnet-ip-over-raw”? Perhaps a sort of “imaginary” version of this might be constructed, almost as an appendix to the Problem Statement?  I mean, having some way(s) to let people visualize more precisely the desired outcome of the exercise I feel would be helpful to the cause.
  9.  “RAW is to provide DetNet elements” – what would those elements look like? How would they differ from the currently defined elements? How are they layered and connected? I don’t mean you have to solve the problem, just visualize what an “ideal” solution would look like.
  10. Is “preserving energy and optimizing the use of the shared spectrum” too large of an ask here? Perhaps those can be orthogonal to “reliable and available transport”, and thus we could simplify the problem? Perhaps they might come along as “free baggage” without having to address them directly?
  11. “possibly combined with wired Segments” – doesn’t this just come for free with DetNet?
  12. “possibly sharing physical resources with non- deterministic traffic” – If this is going to happen below a DetNet flow, shouldn’t this be out of scope? If it is at the level of DetNet flows, then why does RAW need to address this? Again I am just trying to simplify to focus the problem. I gather there is some concern about “is there enough work for a workgroup here” but I feel like the goals of this draft still seem a bit diffuse – I would rather see laser focus on the “just in time” per-packet path decisions, and how that could be interfaced to DetNet. To me that sounds like a substantial task, worthy of a WG (or not to be expected of the DetNet WG, anyway).
  13. “a RAW  solution will need to address less consistent transmissions, energy  conservation and shared spectrum efficiency.” – Same comment as above about teasing these apart. (Same comment for similar text elsewhere).
  14. “it makes sense in the wireless case to  provide redundant forwarding solutions along a complex path and to leave it to the RAW Network Plane to select which of those forwarding solutions are to be used for a given packet based on the current conditions.” – So we are to define the “RAW Network Plane”? Or is that still below us? I think expanding on this idea would be helpful. “leaves it to the forwarding plane to make the per-packet decision of which of these possibilities should be used”. Is the “RAW Network Plane” the “forwarding plane”? If so we should clearly define this and then use this terminology consistently.
  15. “RAW formalizes a routing time scale that is order of magnitude longer than the forwarding time scale” – I think this would be clearer if it were stated the other way around - “RAW formalizes a forwarding time scale that is an order(s) of magnitude shorter than the [wired DetNet] routing time scale”.
  16. “RAW needs feedback that flows on the reverse path and gathers instantaneous values from the radio receivers at each hop to inform back the source and replicating relays so they can make optimized forwarding decisions.” – Perhaps this is the key to the whole thing? It is based on essentially specialized OAM in-band traffic? Maybe that could be shown in the [proposed] diagram?
  17. “There is a need for an observation method to provide the RAW forwarding plane with the specific knowledge of the state of the Track for the type of flow of interest (e.g., for a QoS level of interest).  To observe the whole Track in quasi real time, RAW will consider existing tools such as L2-triggers, DLEP, BFD and in-band and out-of-band OAM.” – Again, maybe this starts to answer my questions? Somehow this key information should be front and center rather than buried late in the Gaps section of the draft? The following paragraphs (i.e. after the afore-quoted one) in the Gaps section all seem to me to be key, and should be up front in trying to describe the approaches considered to solve the problem. Again maybe this could be structured in the form of a “straw man” solution, to give the sense of what RAW is going for.

Anyway so much for my uninformed observations. Please make of it what you will.
Best,
Ethan.








--
Raw mailing list
Raw@ietf.org<mailto:Raw@ietf.org>
https://www.ietf.org/mailman/listinfo/raw<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_raw&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bwwGPCYs7HIsuoFb3vR9ox6I_U38Di5UgB1HxfWzN54&s=0n5wP8rokGd4Ghq4n-q12gVx6bhzUatp9WBxjA_12XI&e=>
--
Raw mailing list
Raw@ietf.org<mailto:Raw@ietf.org>
https://www.ietf.org/mailman/listinfo/raw<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_raw&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bwwGPCYs7HIsuoFb3vR9ox6I_U38Di5UgB1HxfWzN54&s=0n5wP8rokGd4Ghq4n-q12gVx6bhzUatp9WBxjA_12XI&e=>


--
Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mdpi.com_journal_electronics_special-5Fissues_beyond-5F5g&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bwwGPCYs7HIsuoFb3vR9ox6I_U38Di5UgB1HxfWzN54&s=2EtuhHsR2Rlgsmq63ZM11itMH3iM8CiJmnxWfc63FJA&e=>



--
Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mdpi.com_journal_electronics_special-5Fissues_beyond-5F5g&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=-EfvInz0a61MvgaNi9Y6A4MNqiFt_b1k3knraydwve8&s=LwcYZfiUay2Q2pfqXKicQ-XJTvLHgbjflC7pm4hGyzI&e=>