Subject: [Mops] My comments on draft-ietf-mops-streaming-opcons-07

From: Renan Krishna <[email-masked]>
Date: Fri, 7 Jan 2022 12:16:46 +0000

Hi Everyone,
Apologies for the delay in providing this feedback. My comments on draft-ietf-mops-streaming-opcons-07 follow:

Overall comments: The draft provides a timely and comprehensive snapshot of the current operational issues that network operators, service providers, and protocol designers must consider when dealing with streaming video traffic.
These operational issues are not obvious to those without specific video expertise. Therefore, the draft will prove useful for providing such a list of issues against which engineering solutions could be evaluated for standardization at the IETF.  Additionally, Section 7 provides a comprehensive list of references and pointers for anyone interested in a deeper exploration of the operational issues.
I therefore support this draft.

Some minor issues:
1) The scope of the document could be expressed more clearly in the abstract and introduction.
2) Section 2.1.2: Is it possible to provide a reference/explanation for the following line:
"The typical multiplication factor is 8 to 10"
3) Section 2.6:
Suggested change : "faiils" -> "fails"
4) Section 4.6: The text "In addition to measurements....... is providing the best experience for viewers." is repeated.
5) Section 4.6.2:
Suggested change: "assumes" -> "assume"
6) Section 5.3
Suggested change: "....congestion hooks that can be use" -> "....congestion hooks that can be used"
Suggested change: "...congestion controllers in use for TCP base" -> "...congestion controllers in use for TCP based"
7) Section 6.3: The hyperlink for the reference "[RFC7258]" is not working.
8) Section 7.2.4
Presumably,  the following is not meant to be a bullet point but a heading for the bullet points that follow?
" * Low-Latency Live Streaming: The following papers describe the peculiarities of adaptive streaming in low-latency live streaming scenarios."

Regards,
Renan

Dr. Renan Krishna
Staff Engineer | InterDigital
T: +44-20-39221788
E:  [email-masked]<mailto:[email-masked]>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 10 Jan 2022 13:15:59 -0600

Hi, Renan, (plus Ali and Jake),

Thank you for these comments (and I've added you to the Acknowledgements
section). Details below, but only the ones highlighted in yellow are worth
looking at before I commit the changes in Github.

On Fri, Jan 7, 2022 at 6:17 AM Renan Krishna <[email-masked]>
wrote:

> Hi Everyone,
>
> Apologies for the delay in providing this feedback. My comments on
> draft-ietf-mops-streaming-opcons-07 follow:
>
>
>
> Overall comments: The draft provides a timely and comprehensive snapshot
> of the current operational issues that network operators, service
> providers, and protocol designers must consider when dealing with streaming
> video traffic.
>
> These operational issues are not obvious to those without specific video
> expertise. Therefore, the draft will prove useful for providing such a list
> of issues against which engineering solutions could be evaluated for
> standardization at the IETF.  Additionally, Section 7 provides a
> comprehensive list of references and pointers for anyone interested in a
> deeper exploration of the operational issues.
>

Agreed.

I'm working on improvements for the abstract and Introduction, based on
Mike English's review comments, and I'll keep your thoughts in mind. Please
check that the next submitted version of the draft seems clearter to you,
OK? And if you're following the work in
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons, you can
provide comments on
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/pull/94 as
I add commits.

I also made an editorial pass with your minor issues under that same PR.
I'll do a commit soon.

> “The typical multiplication factor is 8 to 10”
>

I don't actually remember where that statement comes from. I'll ask for
help from my co-editors (or anyone else). *Ali and Jake,* the context is

Even basic virtual reality (360-degree) videos that allow users to look
around freely (referred to as "three degrees of freedom", or 3DoF) require
substantially larger bitrates when they are captured and encoded as such
videos require multiple fields of view of the scene. *The typical
multiplication factor is 8 to 10. *Yet, due to smart delivery methods such
as viewport-based or tiled-based streaming, we do not need to send the
whole scene to the user. Instead, the user needs only the portion
corresponding to its viewpoint at any given time.

Honestly, I'm not sure that sentence is even needed ("substantially larger
bitrates" seems to cover a multiplication factor of 8 to 10). But let's try
to do the right thing, either way.

3) Section 2.6:
>
> Suggested change : “faiils” -> “fails”
>

(I'm not seeing this word in -07)

> 4) Section 4.6: The text “In addition to measurements……. is providing the
> best experience for viewers.” is repeated.
>

Fixed

> 5) Section 4.6.2:
>
> Suggested change: “assumes” -> “assume”
>

Fixed.

> 6) Section 5.3
>
> Suggested change: “….congestion hooks that can be use” -> “….congestion
> hooks that can be used”
>

Fixed.

> Suggested change: “…congestion controllers in use for TCP base” ->
> “…congestion controllers in use for TCP based”
>

Fixed.

> 7) Section 6.3: The hyperlink for the reference “[RFC7258]” is not working.
>

Weird. I see what you mean - actually, there is no hyperlink at all in the
third usage/last paragraph.

I'm using the same markdown string - {{RFC7258}} - and it's processed
correctly when the markdown string is used in other places.

I cut and pasted the markdown string from a place where it's processed
correctly into this usage. If that doesn't help, it looks like a tools
issue, which I can report.

Thanks for mentioning this.

> “ * Low-Latency Live Streaming: The following papers describe the
> peculiarities of adaptive streaming in low-latency live streaming
> scenarios.”
>
>
Good catch! I think I see why this was included as a bullet (because it's
part of the ABR material), but I agree it should be a heading.

This is now

### Low-Latency Live Adaptive Streaming

The following papers describe the peculiarities of adaptive streaming in
low-latency live streaming scenarios.

Best,

Spencer

---

From: "Ali C. Begen" <[email-masked]>
Date: Mon, 10 Jan 2022 23:20:23 +0300

> On Jan 10, 2022, at 10:15 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> I don't actually remember where that statement comes from. I'll ask for help from my co-editors (or anyone else). Ali and Jake, the context is 
> 
> Even basic virtual reality (360-degree) videos that allow users to look around freely (referred to as "three degrees of freedom", or 3DoF) require substantially larger bitrates when they are captured and encoded as such videos require multiple fields of view of the scene. The typical multiplication factor is 8 to 10. Yet, due to smart delivery methods such as viewport-based or tiled-based streaming, we do not need to send the whole scene to the user. Instead, the user needs only the portion corresponding to its viewpoint at any given time.
>  
> Honestly, I'm not sure that sentence is even needed ("substantially larger bitrates" seems to cover a multiplication factor of 8 to 10). But let's try to do the right thing, either way.

Yeah, we don’t need to give a specific number, "substantially larger bitrates” is safer and we could cite the following paper as a reference:
A Survey on Adaptive 360o Video Streaming: Solutions, Challenges and Opportunities (https://ieeexplore.ieee.org/document/9133103) which is already listed in 7.2.7.

-acbegen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 11 Jan 2022 08:20:01 -0600

Hi, Ali,

On Mon, Jan 10, 2022 at 2:20 PM Ali C. Begen <[email-masked]>
wrote:

> help from my co-editors (or anyone else). Ali and Jake, the context is
> >
> videos require multiple fields of view of the scene. The typical
> multiplication factor is 8 to 10. Yet, due to smart delivery methods such
> > Honestly, I'm not sure that sentence is even needed ("substantially
> larger bitrates" seems to cover a multiplication factor of 8 to 10). But
> let's try to do the right thing, either way.
>
> Yeah, we don’t need to give a specific number, "substantially larger
> bitrates” is safer and we could cite the following paper as a reference:
> A Survey on Adaptive 360o Video Streaming: Solutions, Challenges and
> Opportunities (https://ieeexplore.ieee.org/document/9133103) which is
> already listed in 7.2.7.
>

I LOVE it when you and I agree on the right thing to do!

Now in my working copy.

Best,

Spencer