Subject: [Raw] Thoughts on Problem Statement draft

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 22 Oct 2019 02:42:25 +0000

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/). 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, 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, 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Oct 2019 06:02:49 +0000

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. <[email-masked]> a écrit :

Hi Pascal et al,

  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/). 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, 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, 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.

--
Raw mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/raw

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 22 Oct 2019 06:58:50 +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.
Ethan.

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Monday, October 21, 2019 11:03 PM
To: Grossman, Ethan A. <[email-masked]>
Cc: [email-masked]
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

Hello Ethan

Pascal

Le 22 oct. 2019 à 04:43, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal et al,

  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.
  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?

--
Raw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/raw

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Tue, 22 Oct 2019 09:12:05 +0200

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. <[email-masked]> 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) <[email-masked]>
> *Sent:* Monday, October 21, 2019 11:03 PM
> *To:* Grossman, Ethan A. <[email-masked]>
> *Cc:* [email-masked]
> *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.
>
>
>
>    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”?
>    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?
>    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.
>
>
>

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

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 22 Oct 2019 17:22:53 +0000

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 <[email-masked]>
Sent: Tuesday, October 22, 2019 12:12 AM
To: Grossman, Ethan A. <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
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. <[email-masked]<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, October 21, 2019 11:03 PM
To: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

Hello Ethan

Pascal

Hi Pascal et al,

--
Raw mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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=>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 22 Oct 2019 17:26:35 +0000

Another image I have is that somehow RAW is a "missing piece of the puzzle" for DetNet. So I imagine RAW as a puzzle piece - where does it fit into the DetNet puzzle (which I am think of in diagrammatic form), where it is so obviously missing?

From: Raw <[email-masked]> On Behalf Of Grossman, Ethan A.
Sent: Monday, October 21, 2019 7:42 PM
To: [email-masked]
Subject: [Raw] Thoughts on Problem Statement draft

Hi Pascal et al,

  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=DwMFAg&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=zFix3ZcI0_xHwLyG71OBJoYcm3F80PHUAL6PSO7omKc&s=EO5dhx5D3Pn_F0h_er7ERllYMD7MsNJBRNS8U5UHxIo&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=DwMFAg&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=zFix3ZcI0_xHwLyG71OBJoYcm3F80PHUAL6PSO7omKc&s=FmmpSCgSZkuw1pBV3v9fn7wVy4f3BAybolGEbPbAqRA&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.
  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=DwMFAg&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=zFix3ZcI0_xHwLyG71OBJoYcm3F80PHUAL6PSO7omKc&s=wEAukEoWSKG21q3BVqvgk-HRnPunpUQsSTtKOxwgv8I&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?

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Tue, 22 Oct 2019 19:41:11 +0200

OK, I'll do that.

Carlos

On Tue, Oct 22, 2019 at 7:22 PM Grossman, Ethan A. <[email-masked]> 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 <[email-masked]>
> *Sent:* Tuesday, October 22, 2019 12:12 AM
> *Cc:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> <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
> [email-masked]
> <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=>
>
>
>
>
> --
>
> <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=>
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Oct 2019 21:41:24 +0000

But there is no absolute need to be congruent is there?

Regards,

Pascal

Le 22 oct. 2019 à 19:23, Grossman, Ethan A. <[email-masked]> a écrit :

Hi Carlos,

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 22 Oct 2019 21:44:49 +0000

Totally up to you. But it seems to me that if this work is being seen as either “offloaded from DetNet” or “inheriting from DetNet” then the basic DetNet tenet that it applies only to centrally administered networks would probably also apply. But maybe not, maybe this work is somehow agnostic to that concept. I don’t know, I’m just pointing it out for your consideration.
Ethan.

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Tuesday, October 22, 2019 2:41 PM
To: Grossman, Ethan A. <[email-masked]>
Cc: CARLOS JESUS BERNARDOS CANO <[email-masked]>; [email-masked]
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

Regards,

Pascal

Le 22 oct. 2019 à 19:23, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Carlos,

From: CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 22, 2019 12:12 AM
To: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>
Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Oct 2019 08:38:19 +0000

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

Sent: mardi 22 octobre 2019 19:41

OK, I'll do that.

Carlos

On Tue, Oct 22, 2019 at 7:22 PM Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> 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.

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Oct 2019 09:42:54 +0000

Good question : )

I think RAW accelerates the work on aspects that are secondary in the wired space, but primordial on wireless. An example aspect is that the separation of routing and forwarding may be operated differently when the links are "distant" from the controller in terms of cost of communication and network-to-controller latency and the frequency of forwarding adaptation requires a local handling.

RAW allows people with wireless interest to congregate and progress on those issues that may not be under limelight at DetNet for eons. The use cases have a large but not full overlap (your point on gaming).

So yes, RAW may start as an overgrown aspect of DetNet. Let's see where it goes from there.

All the best;

Pascal

From: Raw <[email-masked]> On Behalf Of Grossman, Ethan A.
Sent: mardi 22 octobre 2019 19:27
To: [email-masked]
Subject: Re: [Raw] Thoughts on Problem Statement draft

From: Raw <[email-masked]<mailto:[email-masked]>> On Behalf Of Grossman, Ethan A.
Sent: Monday, October 21, 2019 7:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Raw] Thoughts on Problem Statement draft

Hi Pascal et al,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Oct 2019 13:22:08 +0000

Hello Ethan :

Many thanks for the in depth review! Would you wish to co-author? The draft would immensely benefit from you DetNet eye and revisiting the language would be good too.

Let's see below:

<Pascal>
Yes, we should have an early section in that. Would you be willing to propose that text? Your link is spot on and match the industrial terminology that we used to name the mailing list. The definitions, applied to wireless, could be added to the terminology section.

Proposal for this:

2.  Terminology

   RAW reuses terminology defined for DetNet in [DetNet-ARCH], e.g.,

   PREOF for Packet Replication, Elimination and Ordering Functions.

   RAW also reuses terminology defined for 6TiSCH in [6TiSCH-ARCH] such

   as Track.  6TiSCH defined the term Track for that complex path with

   associated PAREO operations.

   RAW defines the following terms:

   PAREO:  Packet (hybrid) ARQ, Replication, Elimination and Ordering.

      PAREO is a superset Of DetNet's PREOF that includes radio-specific

      techniques such as short range broadcast, MUMIMO, constructive

      interference and overhearing, which can be leveraged separately or

      combined to increase the reliability.

   This document reuses terms that are well-defined in the context of

   automation to networking and packet delivery, in particular for

   reliability and availability.  In the context of the RAW work, they

   are defined as follows:

   Reliability:  Reliability is a measure of the probability that an

      item will perform its intended function for a specified interval

      under stated conditions.  For RAW, the service that is expected is

      delivery within a bounded latency and a failure is when the packet

      is either lost or delivered too late.  RAW expresses reliability

      in terms of Mean Time Between Failure (MTBF) and Maximum

      Consecutive Failures (MCF).

   Availability:  Availability is a measure of the relative amount of

      time where a path operates in stated condition, in other words

      (uptime)/(uptime+downtime).  Because a serial wireless path may

      not be good enough to provide the required availability, and even

      2 parallel paths may not be over a longer period of time, the RAW

      availability implies a path that is a lot more complex than what

      DetNet typically envisages (a Track).

In more details:

RAW differs from TSN because the access to the medium at a precise time cannot be guaranteed, and the delivery is statistical. We cannot expect mechanism like pre-emption over the shared medium because we cannot interrupt a remote talker. MUMIMO and Time Slot/Resource Unit/Resource block allocation help a lot but that's still no guarantee. So there will be a latency and a loss budget at each hop, and there will be misses on an individual hop. Because a single path is not good enough to provide the required availability, and even 2 parallel paths may not be over a longer period of time, the RAW availability implies a path that is a lot more complex than what DetNet typically envisages. 6TiSCH defined the term Track for that complex beast. And the definition of reliability expressed in the paper needs adaptation to our use cases. 1) we need to define a "fault" for MTBF: the service that is expected is delivery within bounded latency and a failure is when this does not happen, either the packet is lost or delivered too late. The network must meet reliability criteria that include both MTBF and consecutive faults (losses-in-a-row), e.g., we SHOULD never see LIAR > 3.
</Pascal>

  1.  "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, 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.

<Pascal>
I made that a separate thread. Not ready to give up online gaming. Arguably not a focus for DetNet but a key application for RAW. Happy to rename as you suggest. Dropping implies losing the key Wi-Fi use case.
</Pascal>

  1.  "as a first approximation can ignore flapping" - is the meaning of "flapping" really understood outside the wireless community?

<Pascal>
It is well known at the Routing area, for sure. Fond memories from OSPF and the likes. But for wireless people, I'm not sure. Wireless does not flap like a misbehaving wired interface. We should probably create our definition in the terminology indicating short (typically sub-second) transients where the delivery drops to (almost) zero.

Proposal

   Flapping:  In the context of RAW a link flaps when the connectivity

      is interrupted for short transient times, typically of a subsecond

      duration.

</Pascal>

  1.   "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"?

<Pascal>

Applied

</Pascal>

  1.  Can Informative RFC/drafts be referenced Normatively as done here with the DetNet and RAW Use Case drafts?

<Pascal>

Yes: A normative reference denotes a spec that must be read to fully comprehend this. It is kind of a misnomer and not related to the track.
This draft is informational so it can refer normatively to others without a downref.

</Pascal>

  1.  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.

<Pascal>
DLEP (to my best understanding) provides an abstract interface between a network layer and a radio, e.g. over a cable when the radio is deported, e.g. through a serial cable. It could be seen as a widely augmented L2 trigger, and it is local to a node. The OAM that we need is end to end along a track. It may capture and aggregate information learned through DLEP or other methods.

</Pascal>

  1.  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, 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?

<Pascal>

  Could be useful and could be similar. But the key point is not the functional layout, it is the forwarding plane operation itself. Ideally the most interesting figure would the show the long term control at the controller plane as DetNet has it and the short term control at the forwarding plane that we introduce with RAW.

</Pascal>

  1.  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.

<Pascal>

There could be a DetNet draft like that, yes. And some data models at CCAMP. And bits at BIER. But inside RAW we'll start with OAM and in-band datapath control flows, at least that's what we currently say in https://trac.tools.ietf.org/bof/trac/wiki/RAW

I'm not clear what the proposed version would be but you're most welcome to start some text.

</Pascal>

  1.  "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.

<Pascal>

</Pascal>

  1.  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?

<Pascal>

         Maybe optimizing is too strong? We want to avoid waste as much as can do. How would you word that? If you build many path with tons of redundancy across spectrum, space, time, code, etc..., you'll end up very close to Deterministic but with only minutes of battery.

</Pascal>

  1.  "possibly combined with wired Segments" - doesn't this just come for free with DetNet?

<Pascal>

       Hopefully, that is why we care for DetNet filiation. Again, all rewording welcome, including you taking the pen directly.

</Pascal>

  1.  "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).

<Pascal>

          This is a must for DetNet so we inherit it. It's very hard to omit it since it is a central reason why people say radios are not deterministic.
           With wireless it also means uncontrolled collisions that needs to be combatted, e.g., with MUMIMO and scheduling.
           But I agree with you for now this is not easily tractable, hard to place an action point to match it.

</Pascal>

  1.  "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).

<Pascal>
         I agree on the intention, need a second pass on that.
</Pascal>

  1.  "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.

<Pascal>
         I agree on the intention, need a second pass on that too. Maybe add terminology as well?
</Pascal>

  1.  "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".

<Pascal>
         Applied in the repo; [wired DetNet] became controller plane.
</Pascal>

  1.  "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?

<Pascal>
         Yes, this is key and a diagram will help. I'll need time.
</Pascal>

  1.  "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.

<Pascal>
         Maybe we should rename the section because it is indeed the core of the document. We also need to elaborate in that section.
</Pascal>

Many, many thanks Ethan.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Oct 2019 16:31:42 +0000

Dear all

Time is moving quickly and I posted a first set of changes to address Ethan's comments.
The problem statement will be at the core of our discussion at the next webex on Friday.

Name:                  draft-pthubert-raw-problem-statement

Revision:             04

Title:                     Reliable and Available Wireless Problem Statement

Document date:               2019-10-23

Group:                 Individual Submission

Pages:                  11

URL:            https://www.ietf.org/internet-drafts/draft-pthubert-raw-problem-statement-04.txt

Status:         https://datatracker.ietf.org/doc/draft-pthubert-raw-problem-statement/

Htmlized:       https://tools.ietf.org/html/draft-pthubert-raw-problem-statement-04

Htmlized:       https://datatracker.ietf.org/doc/html/draft-pthubert-raw-problem-statement

Diff:           https://www.ietf.org/rfcdiff?url2=draft-pthubert-raw-problem-statement-04

Abstract:

All the best,

Pascal

Hi Pascal et al,

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 23 Oct 2019 20:07:03 +0000

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) <[email-masked]>
Sent: Wednesday, October 23, 2019 1:38 AM
To: CARLOS JESUS BERNARDOS CANO <[email-masked]>; Grossman, Ethan A. <[email-masked]>
Cc: [email-masked]
Subject: RE: [Raw] Thoughts on Problem Statement draft: gaming

All the best

Pascal

OK, I'll do that.

Carlos

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

--
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=>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Oct 2019 12:22:32 +0000

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. <[email-masked]>
Sent: mercredi 23 octobre 2019 22:07
To: Pascal Thubert (pthubert) <[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]>
Cc: [email-masked]
Subject: RE: [Raw] Thoughts on Problem Statement draft: gaming

To: CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>; Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>

All the best

Pascal

OK, I'll do that.

Carlos

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 24 Oct 2019 18:15:05 +0000

Hi Pascal,
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?

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).

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?

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.

Thanks,
Ethan.

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

Hello Ethan :

All the best

Pascal

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

All the best

Pascal

OK, I'll do that.

Carlos

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Oct 2019 08:01:24 +0000

Hello Ethan

> 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.

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

> 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.

> We certainly don’t!

Pascal
To: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>; CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>

Hello Ethan :

All the best

Pascal

All the best

Pascal

OK, I'll do that.

Carlos

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Fri, 25 Oct 2019 16:53:02 +0200

Dear Ethan, Pascal and Carlos,

Do you think would be wise to merge the Pro Audio and Video with Gaming use-case, since both are related with multimedia.

Georgios

> On Oct 22, 2019, at 09:12, CARLOS JESUS BERNARDOS CANO <[email-masked]> wrote:
> 
> Hi Ethan, Pascal,
> 
> On Tue, Oct 22, 2019 at 8:59 AM Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>> wrote:
> From: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> 
> To: Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> Le 22 oct. 2019 à 04:43, Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>> a écrit :
> 
> 
> 
> Hi Pascal et al,
> 
> “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.”
> “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.
> “as a first approximation can ignore flapping” – is the meaning of “flapping” really understood outside the wireless community?
>  “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”?
> Can Informative RFC/drafts be referenced Normatively as done here with the DetNet and RAW Use Case drafts?
> 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.
> 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?
> 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.
> “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.
> 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?
> “possibly combined with wired Segments” – doesn’t this just come for free with DetNet?
> “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). 
> “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).
> “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.
> “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”.
> “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?
> “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.
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/raw <https://www.ietf.org/mailman/listinfo/raw>-- 
> Raw mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/raw <https://www.ietf.org/mailman/listinfo/raw>
> 
> 
> -- 
> Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g <https://www.mdpi.com/journal/electronics/special_issues/beyond_5g>
> 
> -- 
> Raw mailing list
> [email-masked]

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 25 Oct 2019 14:57:08 +0000

Hi Georgios,
I personally think they should remain separate. In my experience they are considered as separate use cases in the audio/video industry, because they have generally rather different requirements.
Best,
Ethan.

From: Georgios Z. Papadopoulos <[email-masked]>
Sent: Friday, October 25, 2019 7:53 AM
To: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Cc: Grossman, Ethan A. <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

Georgios

On Oct 22, 2019, at 09:12, CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

--
Raw mailing list
[email-masked]<mailto:[email-masked]>
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=PAsnYKVSLg4WD16bYgHAuhNQZXHxDMczOYohhQT735s&s=8JDHT824JKixwjwDb_grWshEAogTthd3J0M7tb1MZVQ&e=>
--
Raw mailing list
[email-masked]<mailto:[email-masked]>
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=PAsnYKVSLg4WD16bYgHAuhNQZXHxDMczOYohhQT735s&s=8JDHT824JKixwjwDb_grWshEAogTthd3J0M7tb1MZVQ&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=PAsnYKVSLg4WD16bYgHAuhNQZXHxDMczOYohhQT735s&s=wTQLTkIxcGjxK-JB8wILsF8QZ3dfP-IkMyqDzGzCx2g&e=>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Oct 2019 17:58:03 +0000

These are 2 different stories, say Madonna’s mike at a concert, and a joystick in the hand of a champion player in an arena. So it might not be easy. But we could present them face to face at the BoF to make the use cases presentation.

The biggest difference might be the temporal inconsistency of the gaming flow. Commonalities are ~ms reaction time, and rare loss, not 2 losses in a row so loss can be compensated by linear regression.

: )

Pascal

Sent: vendredi 25 octobre 2019 16:53

Georgios

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 25 Oct 2019 19:08:16 +0000

Just to reiterate that most of the “techs” we mention don’t seem to have the bandwidth to do pro audio – AFAICT it is just WiFi. Is that really true? Somehow it should be pointed out so as not to mislead people - sufficient BW for the use case is a requirements for a radio link. For gaming I suppose I was assuming that the game controller required audio – maybe if it is just some relatively low bandwidth control signals then it doesn’t need pro audio bandwidth? That may be another distinguishing factor between these two use cases?
Ethan.

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Friday, October 25, 2019 10:58 AM
To: Georgios Z. Papadopoulos <[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]>
Cc: Grossman, Ethan A. <[email-masked]>; [email-masked]
Subject: RE: [Raw] Thoughts on Problem Statement draft: gaming

: )

Pascal

From: Georgios Z. Papadopoulos <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 25 octobre 2019 16:53
To: CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>
Cc: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

Georgios

Hi Ethan, Pascal,

My two cents,

Carlos

Hello Ethan

Pascal

Hi Pascal et al,

--
Raw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/raw<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_raw&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Pomd9KPk1ZeV51ZbtoZb9JgND1BGAPMgdtSje7vJ6mU&s=SIieebuMsPht3CObGBFb7Iw9cECx81NhQ9c8q0k4H10&e=>
--
Raw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/raw<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_raw&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Pomd9KPk1ZeV51ZbtoZb9JgND1BGAPMgdtSje7vJ6mU&s=SIieebuMsPht3CObGBFb7Iw9cECx81NhQ9c8q0k4H10&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=Pomd9KPk1ZeV51ZbtoZb9JgND1BGAPMgdtSje7vJ6mU&s=gzFw-QUMia5wOzYZa0_z_grQjmXqd7AxJ_ArIsV3a7c&e=>

--
Raw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/raw<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_raw&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Pomd9KPk1ZeV51ZbtoZb9JgND1BGAPMgdtSje7vJ6mU&s=SIieebuMsPht3CObGBFb7Iw9cECx81NhQ9c8q0k4H10&e=>

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Sat, 26 Oct 2019 09:39:15 +0200

OK, yes, I can see your example.

Georgios

> On Oct 25, 2019, at 19:58, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> On Oct 22, 2019, at 09:12, CARLOS JESUS BERNARDOS CANO <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Ethan, Pascal,
>  
> “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.”

---

From: John Grant <[email-masked]>
Date: Sat, 26 Oct 2019 12:02:36 +0100

On 25/10/2019 20:08, Grossman, Ethan A. wrote:
> Just to reiterate that most of the “techs” we mention don’t seem to 
> have the bandwidth to do pro audio – AFAICT it is just WiFi. Is that 
> really true? Somehow it should be pointed out so as not to mislead 
> people - sufficient BW for the use case is a requirements for a radio 
> link.
AES67 (standard for audio over IP) isn't used over WiFi because there's 
too much delay.

-- 
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Sat, 26 Oct 2019 16:43:05 +0000

Hi John,
Understood, and as you may recall we actually had text in the DetNet Use Cases draft which said 
"WiFi is pervasive but does not provide guaranteed timing or delivery of packets, and thus is not [usable for DetNet]."
However we removed that text because we were informed by the IEEE WiFi group that they are working on improvements to WiFi to reduce the inherent latency and make it more deterministic, so they didn't want us to rule it out for future applications. There is a summary of those improvements here: 
https://tools.ietf.org/html/draft-thubert-raw-technologies-03#page-10

So we are cautiously optimistic that in time, WiFi will be usable for e.g. AES67 and DetNet. 
Best,
Ethan.

-----Original Message-----
From: Raw <[email-masked]> On Behalf Of John Grant
Sent: Saturday, October 26, 2019 4:03 AM
To: [email-masked]
Subject: Re: [Raw] Thoughts on Problem Statement draft: gaming

> people - sufficient BW for the use case is a requirements for a radio 
AES67 (standard for audio over IP) isn't used over WiFi because there's too much delay.