Re: [Mops] [Internet] My notes on draft-ietf-mops-ar-use-case-03

[Rohit Abhishek <[e-mail]>]

Some comments below for the authors on section 3.

Best Regards,
Rohit

From: Mops <[e-mail]> on behalf of Spencer Dawkins at IETF <[e-mail]>
Date: Saturday, November 6, 2021 at 3:24 PM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [Internet][Mops] My notes on draft-ietf-mops-ar-use-case-03

Dear MOPS,

Leslie reminded me that I had volunteered to send comments on this draft at IETF 111. My apologies for getting distracted since July!

This draft was updated to -03 a couple of weeks ago, so I'm reviewing the current version. I can't stress enough that I'm not an AR expert, although I have co-workers who are, so I'm commenting on the draft as a generalist. Please read these comments as if I had ended each of them with "does that make sense?"

Here are my thoughts.
·         I think it's definitely worth thinking about AR in MOPS. The material on the use case in Section 3 seems useful for operators seeking to better understand AR..
·         It's worth thinking about what the scope of this document is - the title says "Augmented Reality", but there are scattered references to AR/VR and 360 degree streaming  in Section 4. I suspect that most of what section 3 and section 4 are saying about AR would be increasingly true about VR and 360-degree streaming, and a variety of other applications. Perhaps this document should be something like "reasons to deploy edge computing", with the reasons not being about specific applications, but about the characteristics that make edge computing useful, or even critical, for successful application usage.
·         It's worth thinking about who the intended audience for this document is. From the MOPS charter: "The focus of MOPS is on identifying areas where existing protocols and/or networks are challenged by updated requirements". Again, if the scope of this document is to explain why deploying edge computing to support high-bandwidth ultra-low latency applications that need to use network computing resources, that seems squarely within the MOPS charter, and Section 3 seems headed the right direction, but Sections 3.1, 3.2, and 4 contain a lot of details that are only relevant to network operators to the extent that that those details affect the application's demands on the network. I don't think it matters WHY AR headsets place additional demands on networking and computing resources within the operator domain, it only matters that they do place those demands.
Rohit : From what I understand, the AR headset identifies objects in real-time and then overlays a historical 3D scene on top of the identified object. As the user moves, the view of the 3D scene changes. So, when you say “historical scenes in 3D” what exactly does it mean ?. Does it mean a 3D video is overlaid, and it is pre-created and stored somewhere in a server?. As the AR headset points to specific object in a scene, the respective 3D video is streamed onto the user’s headset from the database. If this is not the case, then how are the 3D videos generated and what would be its content?
·         Section 5, on "AR Network Traffic and Interaction with TCP" isn't WRONG, but I don't think it fits in a MOPS document. The choice of transport protocols is still (sadly) up to application developers, and Section 5 would make sense if AR application developers were the target audience for this document. By the time an AR application arrives in a network, the choice to use TCP, or not to use TCP, has already been made, and is largely/completely outside the operator's control.
·
·         This draft definitely needs more working group input, so I hope I'm not the only one who sends comments!. Our experience with putting https://www.ietf.org/archive/id/draft-ietf-mops-streaming-opcons-07.html in Github definitely made it easier for people to contribute comments and text for that draft. I hope it does so for the AR draft as well.
·         The statement that [I-D.ietf-mops-streaming-opcons] doesn't cover AR applications was certainly true when that text was written (the first paragraph of the Introduction hasn't changed since draft-krishna-mops-ar-use-case-01 was submitted in October 2020, when draft-ietf-mops-streaming-opcons was still at -02. It's definitely worth revisiting how this document fits with https://datatracker.ietf.org/doc/draft-ietf-mops-streaming-opcons/, now at -07 and in WGLC.
I hope this is helpful to the working group. If there are questions about my comments, please ask on this list - I'm at IETF 112 all week 🙂.

Best,

Spencer