[Mops] draft-ietf-mops-ar-use-case review

["Holland, Jake" <[e-mail]>]

Hi mops,

I reviewed draft-ietf-mops-ar-use-case-03, and sorry I was so much
later than I promised.  Notes below.

---

Overall:
This doc has some really good observations, and thanks to the
authors for their work here.

I'll reference and +1 Spencer's comments about direction and scope
here:
https://mailarchive.ietf.org/arch/msg/mops/obdNac9sc4ZQ51i4rwFbYCxRvZQ/

I do think this doc should probably turn into something with
more breadth than the specific use case outlined in section 3
(while including coverage of that use case), but I'm not quite
sure in which direction it's best to go.  There are 2 reasonable
directions that occur to me:

Option 1:
Make this document more about the AR space as a whole, with a
section or 2 on the implications for how it drives a need for
edge computing and what parts of AR can and can't be done
without it (which although I'm not an AR expert, I imagine
would imply including more material about different techniques
in implementation like anchoring and probably several others,
and how they impact things like the computational needs for
different kinds of operating environments and use cases--for
instance there are lower-end AR applications like superimposing
cartoon characters in your cell phone images at the park or
during your conference calls that do have tracking and acquisition
issues but don't have head-tracking/motion sickness concerns, and
discussing a spectrum that includes these would be in scope here), or

Option 2:
Make this document more about examples of media use cases currently
being researched and developed that seem to need edge computing
to be practical (which although I'm not an edge compute expert,
I imagine would include some of the mentioned VR/360 points that
Spencer highlighted in the doc, as well as perhaps some other
examples like immersive video games with a VR headset, perhaps
both local to a venue and remotely online).

I went back and watched a little of the prior discussion, and the
author comments seem to merge AR with VR sometimes, which tends to
suggest the 2nd is what was intended.  But as the info about
tracking and acquisition makes clear in the doc, these are really
pretty different in some important ways even though they share some
concerns about head-tracking and motion-sickness-driven latency for
the described history tour use case.  So if the 2nd is the intent,
we probably need this to be more about media requiring edge compute,
with separate sections outlining the different considerations for
the different cases.


So I'm not sure which of these would be best, or if there's other
similar possibilities, but I think covering the one use case seems
too narrow, and the text size as it stands could probably usefully
double or triple with relevant coverage of useful observations in
either of those directions.  (Also worth noting: I think trying to
answer "both" would be a mistake here--the doc should pick a direction
and expand as needed to give a worthwhile overview of the relevant
space, IMO.)

I guess that to me is the first and most important question to
answer here before I know what to say about most of the rest of the
doc.  In retrospect, I kinda wish I had managed to articulate that
feedback before the adoption call, but I do think there's some very
worthwhile things to say in a doc like this on either front, so maybe
it doesn't matter.  (And I wouldn't be opposed to a "both" that takes
the form "actually, this should be a separate doc for each of those
things", though that might be more work than the authors intended to
offer...)

---

With that said, I do have a few points about the rest of the doc
that can hopefully be useful feedback regardless of which direction
it takes.

Abstract:
Probably needs to be tighter, and it seems weird that it highlights
one requirement, I don't quite get why.  I suspect agreeing on an
abstract (or maybe intro) to try to fill a doc in under would be a
decent way to settle the direction question, and would suggest
floating a few proposals for discussion.  But I'll highlight the
editor's advice:
https://www.rfc-editor.org/old/policy.html#policy.abstract

Intro:
- Probably better not to refer to "future" applications as much,
  and just work with "AR applications", or maybe "high fidelity AR
  applications" (or a better-suited industry term if there is one),
  if that's the intended scope.

Use case walkthrough in section 3:
- I'm unclear on whether the user agents in this scenario would be
  venue-owned or not, and this seems like a potentially critical
  issue for understanding what's the intended model.  Is this
  supposed to be about user-owned devices with different platforms
  but similar capabilities, in a way that requires graceful
  degradation for users without these devices, so a variety of
  similar-but-different experience models depending on whether they're
  wearing a next-gen google glass kind of thing or if they're just one
  of the rubes with a smart phone?  Or is this about handing out the
  same kind of device to a bunch of people during their tour, so they
  can all have a fundamentally similar tech experience?  I *think* it's
  the 2nd, but I'm not sure, and that comes with significant implications
  on assumptions we can use for how the service can be operated.

- The doc talks about the scope being "over the internet", but the
  use case seems to be about highly localized traffic in a venue-
  specific network.  I think if this is about internet traffic it
  probably needs to cover more about the target deployment model
  that results in traffic not constrained to a local venue's network.

  I *think* maybe that's about a need for a cloud-based service
  anchor of some kind (url/api endpoint for app/etc) to be able to
  drive the discovery and media-handling delegation to local compute
  resources with certain minimum constraints it can ask for and
  provision?  But the doc I think needs to get a lot more into what
  has to happen here to support the envisioned use case, I think.  I
  think this also has an impact on the "venue-driven" question above,
  because it seems like that kind of model only makes sense if you're
  talking about user-owned devices.  Or is the only internet piece
  of this just the inevitable advertising/purchase confirmation stream
  for the gift shop, which needs to be able to talk between the venue's
  device and the user's wallet manager or credit card?  (A case not
  really in mops's scope, btw.)  Or are we talking about some kind of
  user-owned budget on low-latency compute that comes from their 5g
  provider and takes care of their processing in this tour, so the
  image processing has to link through their mobile device in some
  standard way?  Or is it something else?

---

Summary:

There's some major gaps in this doc, but building a useful structure on
which to hang the outstanding insights and references in the requirements
section seems worthwhile, and I do still think the wg should hammer on
this to see if we can encourage the authors to flesh this out into a doc
we'll be glad we have when these AR/VR customers come knocking.

I hope others will chime in too, and sorry mine took so long. It's not
easy for me to write a review this loosey-goosey; I just feel kinda lost
and confused trying to explain what I'm thinking in a way that might be
useful, so it really helps to have someone poking at me with a sharp stick,
thanks again Leslie for not giving up on that.

Best,
Jake