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

[Spencer Dawkins at IETF <[e-mail]>]

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