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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

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]> 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]>
> *Sent:* Monday, October 21, 2019 11:03 PM
> *To:* Grossman, Ethan A. <[e-mail]>
> *Cc:* [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]> 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]
> https://www.ietf.org/mailman/listinfo/raw
>
> --
> Raw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw
>


-- 
Special Issue "Beyond 5G Evolution":
https://www.mdpi.com/journal/electronics/special_issues/beyond_5g