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

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Tue, 22 October 2019 17:41 UTC

Return-Path: <cjbc@it.uc3m.es>
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 A4AAC1208F3 for <raw@ietfa.amsl.com>; Tue, 22 Oct 2019 10:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 1_dyOcRhzq79 for <raw@ietfa.amsl.com>; Tue, 22 Oct 2019 10:41:30 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDB11208EC for <raw@ietf.org>; Tue, 22 Oct 2019 10:41:29 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id b72so4598177edf.1 for <raw@ietf.org>; Tue, 22 Oct 2019 10:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qzpY5L5ZpqDtWfNrPEKenRu8myQKfaWza2TxKU455Q4=; b=FeuAkFaXbHa8eeY+CceZaX05dOYi/0YzTRca9BrVfMnKblvxgZxMboV5mdSQuLY09n enoLhzMTEeBxr9fg1WqLMiIesbKgO7Lja8ApDtKsJh5Z2RieuCftKz27coql7HSk8v60 iqFME48m4Kv6ic7kmaoU70g2niBqb2ic7ahm+v0LwLn8aex3Sl8CdUKR/2tUZDMuy9ng E6CoVW8veeC+1vlQsGySh5i5LlOoKXc7pdLdTsoKH0q4uNtP+O1PxotdZMiKt2K/5JRC h2CuWBUQG8HppFiUFOUFYxPLskIvv4rXGVfqqoVPs9XfxpBK75rYydp3i2uV01YHsSmy L90w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qzpY5L5ZpqDtWfNrPEKenRu8myQKfaWza2TxKU455Q4=; b=SvCg5mjUH3O8sNVz2HPJQHd5C8PPgjTWtHyIwybRfnASILOySf+vd0oh/ANcFd39Oc 7Y9sQgbFva1zDDyYtmVJ0HOG2c7Kd5S5Dpbr3DkFmEjwi8vPAiRs2eMdB+lrJuPQ0UuO BTt9BuUAKCsf9gGNlX5KR6mg/BeiJ2DRfN78dJShhsNtj8AqsxagseWEYjeEFnrYp6/W SgrFfifFzga3+X15ZajT+ntRYpVFKU0OX9bgLWTox/SZzVZGuO79l3kqZVzfwgyZug4U PkR2KSWjpMvXDR6++3WdrB97PEIBlU/4zQZVfadrBmmWbLU+1M/lWPbJ+ZMoym3rAitU XmuQ==
X-Gm-Message-State: APjAAAXgQmEzPj6LXwGULAGqE8/5xPuIL12tQ99VzcaViSM6Z7dt8If/ tJz0mZlUzaN92GW9nzX0kTMmLz+MEM5YSPQT0d/VVuZyjis=
X-Google-Smtp-Source: APXvYqx4tOYp4sMIlNstMQUyvigmfxxfds+l3/Nq3smEK8wfJrtiyVkPLI11CB4Rhe6ybJ9kX/ECzzJdYA+X2kbt7eU=
X-Received: by 2002:a17:906:d72:: with SMTP id s18mr12632557ejh.29.1571766087418; Tue, 22 Oct 2019 10:41:27 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <BYAPR06MB43257C7A0DC1E85B82D22178C4680@BYAPR06MB4325.namprd06.prod.outlook.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Tue, 22 Oct 2019 19:41:11 +0200
Message-ID: <CALypLp8XvRo39aA4v5jKCoo3-pwLYrHxktwiQbVVg27nE5-JNg@mail.gmail.com>
To: "Grossman, Ethan A." <eagros@dolby.com>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "raw@ietf.org" <raw@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004fa9140595834f87"
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/qNig1B4SLSZ0s95iAX4iovhuzqQ>
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: Tue, 22 Oct 2019 17:41:35 -0000

OK, I'll do that.

Carlos

On Tue, Oct 22, 2019 at 7:22 PM Grossman, Ethan A. <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>
> *Sent:* Tuesday, October 22, 2019 12:12 AM
> *To:* Grossman, Ethan A. <eagros@dolby.com>
> *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com>om>; 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>
> 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>
> *Sent:* Monday, October 21, 2019 11:03 PM
> *To:* Grossman, Ethan A. <eagros@dolby.com>
> *Cc:* 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> 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
> 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
> 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