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

[Renan Krishna <[e-mail]>]

Hi Jake,

Many thanks for your comments and apologies for the delayed response. Please see our response inline. Additionally, we have updated the Abstract and Introduction in version "04" of the draft to define our intended scope.

Regards,
Renan

-----Original Message-----
From: Holland, Jake <[e-mail]> 
Sent: Thursday, November 11, 2021 12:24 PM
To: [e-mail]; [e-mail]
Subject: draft-ietf-mops-ar-use-case review

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

[RK] We would go for option2 and the updated version "04" reflects this in the abstract and introduction

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.

[RK] Agreed, we will re-structure the draft to be more about media requiring edge compute . We have changed the abstract and introduction accordingly and will have separate sections for 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.)

[RK] As discussed above, we would like to go for option 2..

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
[RK] Thanks for the link! We have re-written the abstract in version "04" of the draft

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.
[RK] We have re-written the intro and replaced AR with Extended Reality (XR) in "04"

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.
[RK] We propose that the Agents will be venue owned because it affords(for now) a simpler engineering problem- so it is option 2! 

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

[RK] We limit our scope to highly localized traffic in a venue specific network generated by a venue-owned device as that "seems" to be a simpler engineering problem to be targeted first..

---

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