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

CARLOS JESUS BERNARDOS CANO <> Tue, 22 October 2019 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5062812004F for <>; Tue, 22 Oct 2019 00:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mFoK4Fg5Rx2J for <>; Tue, 22 Oct 2019 00:12:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69EB512002F for <>; Tue, 22 Oct 2019 00:12:24 -0700 (PDT)
Received: by with SMTP id r16so12006386edq.11 for <>; Tue, 22 Oct 2019 00:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e06sIwi7rBhF47oxcSw/DxyI0075HFd1Dv7MOrz2vys=; b=DiIK2ahJ8n6UN+8YF4oeyGfLFVxSJdd9kkn8rGnDYchNAVT8Q9xz7oMGO1sF3aD5ie aBuc9+HliNkLFu9o/g71/UqgFEUaRtMv7aW89M+dkTNZyN/4bW31k87RbpcbHxwaBhcu WbZBNnmYu6rrl2WuVE9qhD5FxQO9ibsMSBpJmAcXzhsX9sU6G+hEOcmyMjipp0wvw7LX tKgNvJcSruQmitcDWNzBqoslkRDxbbL/+X2CTN/2XTIkd/ZbN8924ejuTz+V+bDzopyt j0k/oJdc/k4+LCBYq+TUBw/Cvy35aY+xE7UHwjTONddulUkqDg3TVXElEqfMeL8KzY4B K28Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e06sIwi7rBhF47oxcSw/DxyI0075HFd1Dv7MOrz2vys=; b=YHOjcaVrQM/Hx7db8UdKwxIbh5GZa6F+QBidlYJILbOacuzdnV6ArK+zfMVuplXjxb S19lL7VFj6/87vAuEGm5PnkTV1gRLbsG9EsRhGsBsSARK/Ft/nWuevOfiMdzW/R4bk5X Kg2hpt+8cpeH7a3jKhdGOdybZqEZP/8PiyKIwGfutirB5SFQa4bWQqQfUKnkfi6owvk8 NknJbn7jPXcXL33rkYzLWXWdPWhuKasmVogwetHNwSCFejqxap4z6xdAyv+taiJ4IZez r8CDWl8SadHlTR5BLLx1sY2vnNirVBsyuADLVanw31fJyL0FkEQij7O61vegP+1mEcFf NbNQ==
X-Gm-Message-State: APjAAAUX4aJ9m/WsbY+oE8ZjDyEwa0TQF8if8UVISs2pZdBbcIxPcX0Q 25oK1BtZocxkmtQ3AKGSaKuF0LLTmHlHEVSj+dDTNA==
X-Google-Smtp-Source: APXvYqxihSNKfEk0g2SS6L6lCE+I+S0Szb5JHf+B/jIgQM57rw44KRCApbAcRfGa6tJVLDjLC5ZijWe7iyAfcORsKgU=
X-Received: by 2002:aa7:d915:: with SMTP id a21mr29620928edr.46.1571728342645; Tue, 22 Oct 2019 00:12:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Date: Tue, 22 Oct 2019 09:12:05 +0200
Message-ID: <>
To: "Grossman, Ethan A." <>
Cc: "Pascal Thubert (pthubert)" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008c1ef105957a85ea"
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 07:12:29 -0000

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,


On Tue, Oct 22, 2019 at 8:59 AM Grossman, Ethan A. <> 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) <>
> *Sent:* Monday, October 21, 2019 11:03 PM
> *To:* Grossman, Ethan A. <>
> *Cc:*
> *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. <> 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.
>    <>).
>    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
>    <>,
>    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
>    <>,
>    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 mailing list

Special Issue "Beyond 5G Evolution":