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

From: Renan Krishna <[email-masked]>
Date: Wed, 16 Mar 2022 17:05:58 +0000

Hi Kiran,

Many Thanks for your comments and apologies for the delayed response. We agree with the points made by Prof. Ali Begen in response to your questions- many thanks to him as well . We would also heartily endorse the survey paper mentioned by him. Please see our response inline.

Regards,
Renan

From: Mops <[email-masked]> On Behalf Of Kiran Makhijani
Sent: Tuesday, January 18, 2022 7:10 AM
To: [email-masked]
Cc: [email-masked]; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: [Mops] [Internet] My notes on draft-ietf-mops-ar-use-case-03

External Mail

Hello Authors,
I went through the document out of interest in the topic and I am no expert in AR. Spencer's comments are very valid. I also felt there there are two or three different things going on in the document - edge compute relevance, processing-overheads and ABR.
Of these ABR discussion may be worth exploring more. For example, the tolerance to packet loss is not covered as a requirement. Is there a requirement or should it be to change data rates in order prevent packet loss. I was also curious to know will there be a requirement on chunk sizes of a stream? Since  headsets do not have a lot of buffering capability and the field of view will change  quickly, would you recommend chunk (or segment) durations to be shorter? I guess another requirement to explore will be will there be more than one  stream sent to the headset if  some movement prediction is used? In that case do bit-rates for those streams need to match. Last one - bit-rate negotiation may be initiated  by the headset because they may have different capabilities (processing, buffering ). Basically, getting into the streaming specific section will be more interesting to me.

Some other nits:

  *   in section 3.1, when you say mobile device do you really mean headset?
[RK] yes, we mean headset-sorry for not being clear.

  *   You have used terms like situated visualization, temporal coherence, natural features, lack of visual features in the grid environment - none of these were immediately obvious to me. perhaps define them for casual readers/newbies.
[RK] Agreed

  *   chapter 4, first bullet - what type of AI/ML  processing will be needed.
[RK] We mean using in-situ data as an input for AI/ML processing– please refer to the reference {ABR_2] in the draft.
Hope this helps.
Cheers
Kiran
On Jan 15 2022, at 8:14 am, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
Dear MOPS,

Just following up here - I know that the draft authors thanked Rohit and I for our reviews during the MOPS session at IETF 112, but is anyone else sending review comments to the working group?

Best,

Spencer

On Tue, Nov 9, 2021 at 8:45 AM Rohit Abhishek <[email-masked]<mailto:[email-masked]>> wrote:
Some comments below for the authors on section 3.

Best Regards,

Rohit

From: Mops <[email-masked]<mailto:[email-masked]>> on behalf of Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 6, 2021 at 3:24 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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
--
Mops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mops
--
Mops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mops

---

From: Renan Krishna <[email-masked]>
Date: Wed, 16 Mar 2022 17:07:08 +0000

Many Thanks for your input Ali!
Regards,
Renan

From: Mops <[email-masked]> On Behalf Of Ali C. Begen
Sent: Tuesday, January 18, 2022 6:15 PM
To: Kiran Makhijani <[email-masked]>
Cc: [email-masked]; [email-masked]; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: [Mops] [Internet] My notes on draft-ietf-mops-ar-use-case-03

External Mail
I am not an author of this draft, but wanted to provide some input:

Of these ABR discussion may be worth exploring more. For example, the tolerance to packet loss is not covered as a requirement. Is there a requirement or should it be to change data rates in order prevent packet loss.

Well considering the HTTP-based adaptive streaming (ABR as you call it), there is no tolerance to packet loss per se since media is almost always carried over TCP (does not have to be but it is what it is). So, there is no such thing as tolerance to packet loss in the ABR domain. Rather as the throughput achieved by the transport varies (plus some other factors), the streaming clients adapt by picking a different version of the watched content.

I was also curious to know will there be a requirement on chunk sizes of a stream?

Chunk/segment sizes depend on two things: encoding bitrate (target) and chunk/segment duration. There are pros and cons for large/small sizes (and long/short) durations. The ABR survey paper cited in the opcons draft touches on this issue. But at the end, it does not (and cannot) draw requirements.

Since  headsets do not have a lot of buffering capability and the field of view will change  quickly, would you recommend chunk (or segment) durations to be shorter?

Since the viewport may change at any time, unless you are fetching and storing the whole 360 video (very unlikely), you will never want to keep several seconds worth of media on the device anyway. So, this means your segments will have to be shorter compared to the case of traditional/non-VR content.

I guess another requirement to explore will be will there be more than one  stream sent to the headset if  some movement prediction is used?

If you are referring to the viewport-dependent delivery or tiled streaming, the 360 video will be transmitted over multiple streams like the viewport being streamed in high quality and other parts being streamed in low quality. If viewport prediction is used, you may certainly fetch some of the parts (tiles) in high quality, too, in the anticipation that those parts will be viewed by the user. They may be streamed over an existing stream or a new one. This depends on the tiling scheme, your HTTP version and such.

In that case do bit-rates for those streams need to match.

No, it is entirely up to your preference (ABR algorithm). As a matter of fact, we have an ongoing study looking into all these things and it is in the review process. When it gets published, I will be happy to share the results.

Last one - bit-rate negotiation may be initiated  by the headset because they may have different capabilities (processing, buffering ). Basically, getting into the streaming specific section will be more interesting to me.

Client-driven ABR gives you this capability already. The client on your headset should determine/know what it can do or cannot do. The server is only offering what is available, it is the client's responsibility to get the right thing.

While at it, I would like to ask the authors to reconsider touching on the generic ABR related matters, which are already detailed in the opcons draft and frankly, only the AR/VR specific details should be kept in this draft. That will ease the reading and reduce any potential confusion.

-acbegen