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

"Grossman, Ethan A." <> Tue, 22 October 2019 06:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEC33120B0C for <>; Mon, 21 Oct 2019 23:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EF_sSkY0t9U2 for <>; Mon, 21 Oct 2019 23:58:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0057812002F for <>; Mon, 21 Oct 2019 23:58:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=VFIiZp48x0g5ytoOdh2CaV7LUB4s9n+SsR5d39nxe63VdYLs/ZUc5qzo9VDwd8lcQxYPNwBEAqBAQWEqByIAeDjQdhsDD4yeemIG1ASxjLTmsEU6a9+HP+8sxWbpY8ioK7oAmwzvzDA4nvgEfxR4DWPElNsNDdG3pa8GL0YOshg3wdERzoIuH+jGqLELAdHhmQjgEKRF9qJV6Q2NwQagodGTWG4ZixK753AaslSdWuK3vNs602gT6GcmFn4uFuvc6aYaH2Oz3m83ZeDyT6lSaZn+hq5fzBv3t14CjJzRBLPYcbWL6MIgqXRysjtIbIsBBEF7petUwvz1XKSDRzl2+A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HjC1bRXL5n8l17yNGB7VTBUkoOwQEU043mjQ1vPAY7g=; b=Dq7uapTZROflGH0O2oiYUU/yF/t9nprKB8usBQAWSyISCZPxINF4cYVL4Ou4hQqjBKEbIGttASs5881a3JOCf1PCo9rXS8DFgAuo3XRvLDOholULdAsFjkp/IkO6Kyeu1SFPysf32PSHo+u0mnzcP4kb4a3GANAJWdza1/Xt9RaMKYkYiuwaBOeAq0wiQDh5V0xLML7mJ32h3ARNOpuGgU/VzumBnt1Y8wRQ5p+s04UxFF8EElYzg9CcX1UkhUBzE7D1Zzj5RvT3Nsm0Ouefqo1ofpK+m6HM7/DRzMDS99a+ilqxwYA8ExGsA/TIReFBoNDAFmpEz6ittcgd3zl9Cw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HjC1bRXL5n8l17yNGB7VTBUkoOwQEU043mjQ1vPAY7g=; b=Z9ocJRiwR6xt4q0d/mdqkAkGx2CH09lqrk8zyvi5CmGhYWvM5wogAjMeI5r8+gi22JSEPUSzU3M9IAoFswADswRgiY3fXtXV+HfHMa6Rmtq1c3xbA4U6ay7KiBo29Bicp16+lgKbwVbPN3craSYo804hAsCpgbhcBH7swjLKeek=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Tue, 22 Oct 2019 06:58:50 +0000
Received: from ([fe80::4133:d57b:b32e:99b8]) by ([fe80::4133:d57b:b32e:99b8%3]) with mapi id 15.20.2347.028; Tue, 22 Oct 2019 06:58:50 +0000
From: "Grossman, Ethan A." <>
To: "Pascal Thubert (pthubert)" <>
CC: "" <>
Thread-Topic: [Raw] Thoughts on Problem Statement draft: gaming
Thread-Index: AQHViJ5a0grUOmBiyEKSyCgBuaMzdqdmOs5A
Date: Tue, 22 Oct 2019 06:58:50 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fee06967-ee0c-458f-7c0c-08d756bd4b28
x-ms-traffictypediagnostic: BYAPR06MB3895:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 01986AE76B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(136003)(376002)(396003)(189003)(199004)(43544003)(790700001)(7696005)(8936002)(7736002)(33656002)(6116002)(229853002)(99286004)(606006)(4326008)(76176011)(6916009)(6246003)(316002)(256004)(14444005)(2906002)(74316002)(71190400001)(71200400001)(3846002)(81166006)(6306002)(54896002)(11346002)(446003)(66946007)(5660300002)(8676002)(66574012)(486006)(9686003)(186003)(6436002)(76116006)(53546011)(966005)(86362001)(52536014)(6506007)(55016002)(102836004)(14454004)(26005)(236005)(25786009)(478600001)(66066001)(66556008)(64756008)(476003)(66446008)(81156014)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB3895;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BLrI1TW3GvLM3jdX7GOwZYdKzLPi7DD9uQNPKjB1wDxiH0kDKe4FqvYuUcuwF3fVr7VpQd1mPKvBf5nqMjCK1gEtd91D39cPZbNWfIu22+DPs6tL3lb+oQF4DA8LiaiJnwRTux4SePapN392+OtzZ355fv01/ml/mmn0ceuDpddWUHq5WLbLpLh0cJy8nba0H0FFxpAsohL8eLfBA1klVMsMJxVSrFk1+l+xxhRHwiy6L9/lB3F0vPc5/6u8E0/fP9VIlI/c0a/F+M7TOKhG8S+rxJ/UKByFe1U2ksLKRknpw+kdECH/HTer6JdDOe4fi7rmV6+JET+isb7XcQGjx1HFypBhtldaTpCqiHqhxEFhPP88hsqG762acdkuV6UghYOef3G0mm0LHwz1tcmOWUs+l33vIQYbOAyPTxolCDpakpzF902JGN57TBV5gljvhPseF1GPb8MnV70mbyhsZg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR06MB4325B7F3BA0E1B330CDA8840C4680BYAPR06MB4325namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fee06967-ee0c-458f-7c0c-08d756bd4b28
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 06:58:50.3597 (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: s4JX2JryktDSZFUzwfvsYxaTyVrqzhnpPtQkLmLqLxK6sT8k9LIgKqxSzHPoXYAhAPNDrgdK8s0TquamecWIXQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB3895
Archived-At: <>
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: reliable and available wireless <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Oct 2019 06:58:59 -0000

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.

From: Pascal Thubert (pthubert) <>
Sent: Monday, October 21, 2019 11:03 PM
To: Grossman, Ethan A. <>
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,


Le 22 oct. 2019 à 04:43, Grossman, Ethan A. <<>> 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.<>)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<>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<>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.

Raw mailing list<>