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

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

Hello Ethan


Actually I was not suggesting that we be an “over foo technology”; I am just trying to understand the goals and scope, and that was a pure question. Actually I honestly thought that the answer to that question (“if we just consider “what is RAW for WiFi” by itself, what do we have?”) would be “nothing”. In other words if WiFi gets fixed up to provide deterministic latency and relatively low packet loss, such that you put packets in one side and get packets out the other side in a timely fashion, why can’t DetNet treat that exactly the same as a TSN sub-network, given that the user understands the limitations imposed by the shared airspace?

In yet other words, my understanding is that WiFi can’t be “micromanaged” with respect to real-time per-packet path decisions, not least because it is (at least for purposes of gaming and audio and industrial use cases) nominally a point-to-point connection implemented in a “black box” radio chip that doesn’t have any meaningful dials that can be operated in real-time by a controller plane. Is that true?


> Yes, the RAW problem is not a one-hop problem but how to use multipath to compensate the indeterminism of one hop. Multipath may range from parallel one hops on a same technologies, to a DAG to a destination with links of various technologies. Whether it’s 5G or WiFi6, we have a very rough abstraction of the scheduler and of the resource block, and cannot enforce their exact location in frequency and time. But we can place boundaries on when they should be transported so the end to end traffic is served per SLA. The way we express multipath on radios is different from wire, e.g., overhearing can be used to compensate lossiness and that needs to be integrated in the controller’s abstraction of the network.

So even the notion of considering the focus of RAW to be WiFi is surprising to me, although I have to say it would make RAW a lot better aligned with the interests of my employer and our industry (Pro and Consumer Audio/Video).

> Wi-Fi made a great progress towards RAW capabilities with .ax, and more is expected from .be.

Can you explain what our work would be like (or how our charter would change) if we were to start with WiFi, and defer other foos? I mean, what would/could we do? Presumably reporting back to the Controller on the state/throughput/PLR of WiFi links could be done with existing methods?

> I would not see much change. We’d have less ground to prove that the methods we develop are generic enough. 6LoWPAN started with just one foo, 802.15.4, and now works on a dozen technologies from PLC to BLE and NFC.

And of course many contributors to RAW have other interests besides WiFi, so we don’t want to make a complete left turn and lose everyone.

> We certainly don’t!

Pascal
From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 24, 2019 5:23 AM
To: Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>; CARLOS JESUS BERNARDOS CANO <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Raw] Thoughts on Problem Statement draft: gaming

Hello Ethan :

Wi-Fi may become the core focus since TSCH is already very advanced already and 5G is not well represented n the RAW audience right now.
Now so far we said that we do not aim at being an over foo technology. Are you saying that maybe we should and maybe foo = 802.11 ax/be ?

All the best

Pascal

From: Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>
Sent: mercredi 23 octobre 2019 22:07
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; CARLOS JESUS BERNARDOS CANO <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Raw] Thoughts on Problem Statement draft: gaming

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) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, October 23, 2019 1:38 AM
To: CARLOS JESUS BERNARDOS CANO <[e-mail]<mailto:[e-mail]>>; Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: mardi 22 octobre 2019 19:41
To: Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>
Cc: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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. <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 22, 2019 12:12 AM
To: Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>
Cc: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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. <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, October 21, 2019 11:03 PM
To: Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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. <[e-mail]<mailto:[e-mail]>> 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=>). 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=>, 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=>, 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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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=>