Ballot for draft-ietf-raw-use-cases
Yes
No Objection
Abstain
Note: This ballot was opened for revision 08 and is now closed.
# Internet AD comments for draft-ietf-raw-use-cases-08 CC @ekline ## Nits ### S2.2 * In Figure 1 description: - "Termina" -> "Terminal" - "domain domain" -> "domain"?
I support Roman's DISCUSS, and I find Martin's ABSTAIN discussion to be compelling. Just out of curiosity, was the DRIP WG consulted for any input or feedback regarding Section 7?
Thanks to Roman for his discuss and comments! I can only add that I found the wireless gaming a little contrived, as what really matters for gaming is the home internet connection. Die hard gamers will only use modern switches and cabling to hook up their consoles and stay away from wifi completely to ensure it is only their home network that is the limiting factor. I interpreted the text to mean it is trying to solve this in a way that wifi can be used in this scenario (although the real latency/loss issue is still the home internet connection quality)
Thank you for addressing my DISCUSS and substantive COMMENTs. === ** Section 2.5. Different safety levels need to be supported, from extremely safety critical ones requiring low latency, such as a WAKE warning - a warning that two aircraft come dangerously close to each other - and high resiliency, to less safety critical ones requiring low-medium latency for services such as WXGRAPH - graphical weather data. I can appreciate the abstract idea of using certain information for safety critical decision making. However, can more detail be provided to translate the “safety levels” to requirements of the data link or the “RAW protocol”? Mentioned already seems to be “low” vs. “low-medium” latency; and “high resiliency” which should be read as guaranteed delivery or ability to use multiple paths/radio technologies? Or is “low latency” translated into a design as the subsequent text suggests of “small packets” and resiliency primarily about “choosing links” ** Section 2.5.*. Low latency is stated as a requirement a few times. Can this be expressed quantitatively? Use case owners (and readers) might have their own subjective idea of what constitutes “low”. ** Section 3.2. Some non-time-critical tasks may rather use the cloud (predictive maintenance, marketing). -- Marketing is mentioned as an example of a computational workload appropriate for the cloud but it isn’t noted as an application in Section 3.1. Perhaps it should be made more explicit. -- If these tasks are “non-time-critical”, why can’t traditional wireless technologies address them (i.e., why can’t they be solved without RAW)? ** Section 6.1. But Wi-Fi has an especially bad reputation among the gaming community. The main reasons are high latency, lag spikes, and jitter. This statement is suggestion a subjective assessment of the user experience. Is it technically accurate?
# Éric Vyncke, INT AD, comments for draft-ietf-raw-use-cases-08 CC @evyncke Thank you for the work put into this document. I really like the common format used for all the use cases. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Corinna Schmitt for the shepherd's detailed write-up including the WG consensus *but* with a very weird justification of the intended status. Please note that Suresh Krishnan is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well: https://datatracker.ietf.org/doc/review-ietf-raw-use-cases-08-intdir-telechat-krishnan-2022-11-28/ (I saw that Carlos has already replied) I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Shepherd's write-up The justification for the intended status is really weird and outdated (such write-ups can be updated): ``` Standard Track is mentioned, but reading it I assume “Informational” is meant. Request is send out. ``` ### Quantitative approach ? While this I-D is easy and interesting to read, it would have been more useful if actual numbers were given per use case, e.g., bounded latency, max packet loss, ... ### Section 1 Is the use of capitalized "Deterministic Networking" a reference to the work of the DETNET WG ? Then, let's state it else suggest not to use capitalized words. Later in the text "DetNet" is used, it would be nice to use a common naming. ### Section 4.3 Are "Ethernet cables" still used ? As opposed to optical fiber (notably for noise reduction) ### Section 5 Suggest to add a reference to RFC 9317 "Operational Considerations for Streaming Media" ### Section 7 Like Murray, I wonder whether DRIP & IPWAVE WGs were made aware of this section. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
Thank you for the document, I found it to be an informative read that was clear and well-written. I do, however, find myself supporting Roman's discuss.
Hi, Thanks for an informative read. I just had one minor question/comment on this doc: * Wireless Console Gaming: Playing online on a console has 2 types of internet connectivity, which is either wired or Wi-Fi. Most of the gaming consoles today support Wi-Fi 5. But Wi-Fi has an especially bad reputation among the gaming community. The main reasons are high latency, lag spikes, and jitter. Is the concern here just about how the console is connected to the Internet (which could be wired or wireless), and/or how the handheld controllers are connected to the console (which could also be wired or wireless)? Presumably both of these could be in scope for RAW? E.g., I thought that one of the alleged benefits of Google's project Stadia was that it was meant to reduce latency for cloud gaming via going directly from the handheld controller to the router without going via a console or PC. Thanks, Rob
I see no flaws in this Informational document that rise to the level of a DISCUSS, but its current form I don't think it is a particularly useful contribution to the RFC series. It would need a major revision to reach that level, in my opinion. Broadly speaking, the document describes a number of wireless use cases, but doesn't create a unified framework of requirements associated with them, certainly doesn't make the case that a detnet-style solution is appropriate. Here is a non-exhaustive list of examples: (2.3) "It is necessary to keep latency, time and data overhead of new aeronautical datalinks at a minimum." 'At a minimum' is not a real requirement: these things are always traded off against other design considerations. A completely integrated, bespoke protocol stack with custom hardware all along the path is always the way to get "minimum" latency, but this is impossible in practice. Instead, there should be a number attached to the metric, or at least "similar latency to interactive voice", or whatever. (3.4) "The network infrastructure must support heterogeneous traffic, with very different critical requirements. Thus, flow isolation must be provided." Individual identification of flows doesn't follow at all. The whole concept of Diffserv is to provide differentiated services without identifying individual flows. (6.4.1) "But note that in most of these scenarios, part of the communication path is not wireless and DetNet mechanisms cannot be applied easily (e.g., when the public Internet is involved), and therefore in these cases, reliability is the critical requirement." If I read this correctly, it's saying "low latency would be nice but we can't actually guarantee it". Reliability without hard latency bounds already has a solution: TCP. (8.4) "When a given service is decomposed into functions -- hosted at different robots -- chained, each link connecting two given functions would have a well-defined set of requirements (latency, bandwidth and jitter) that must be met." For this use case, you throw up your hands and say "requirements depend on the application," which is the most banal statement possible. This is indicative of the problem that this use case document is identifying market segments rather than technical requirements that will drive the work. As it stands, this use case provides zero motivation for RAW rather than existing protocol solutions. (9.4) "The inter-network needs to operate in damaged state (e.g. during an earthquake aftermath, heavy weather, wildfire, etc.). In addition to continuity of operations, rapid restore is a needed characteristic." Robustness to infrastructure damage is one of the original design requirements of the Internet, and does not motivate new work. ... and so on. A much better approach to this document would articulate specific requirements levied on the network that are not well served by existing standards, and then tie those shortfalls into specific use cases.