Re: [Mops] Comments on draft-ietf-mops-streaming-opcons-06.txt

Hi Kiran

> On Aug 26, 2021, at 10:22 PM, Kiran Makhijani <kiran.ietf@gmail.com> wrote:
> 
> Hi Authors,
> The document has done a great job in putting together lot of valuable
> information. I personally feel that some clarifications may be added to
> see the whole picture but not sure if they are in the scope. So I look
> forward to your replies (PS: I was not sure if I should have posted it
> on WG mailing list or github).

List is fine.

> 1. General - I wonder if the document could also include  considerations
> in terms of reference architecture and deployment. The reason is that
> the document covers transport, QoS (bandwidth, latency), encryption,
> media format but not much on network layer or connectivity aspects such
> as selection of CDN servers. Then, having insights into deployment will
> also help determine challenges for new applications or infrastructures
> (such as those from 5G world). 

We might provide a brief text on this (anybody is welcome to propose one). Or better yet, we might provide a few references on this subject for 
further reading. See the current list of further reading we are compiling for this draft here:
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/14

(Feel free to add other references to the google doc)

> 
> 2. In Section 1. Introduction
> 133    milliseconds whereas live streaming can tolerate latencies of several
> ^^^^^
> Shouldn't this be on-demand streaming? I mean there is real-time
> streaming of a sports event and then there is on-demand streaming. 

Please check section 3.

> 3. Section 3.2
> ...the latency can be decoupled from the duration of the media
> segments. 
> Just a clarification - How latency can be decoupled? Do you mean the
> arrival times of segments is independent from the playing time?

It means the latency does not depend on the segment duration anymore. You can use larger segments but still achieve low latency using this approach.

> 4. Section 4.5.2
> In this section, it is bit unintuitive how CDNs do not have per session
> visibility. if the content should be fetched from server, I am guessing
> the application logic will keep at least the ephemeral state on the
> server (either at transport or application level).
> Maybe the reason is since HTTP is stateless, therefore, application does
> not know about the state. Am I right?

HTTP is stateless, yes. Even if a server indeed keeps more logs, those logs will not necessarily tell the server (or the CDN) exactly what they were corresponding unless you post-process/analyze them with some extra knowledge about what each requested object was referring to.In other words, the server/CDN does not have the knowledge of correlating the requests and aggregating them into sessions. With each requested object, there is something more needed to make that correlation and that is what CMCD does.

-acbegen

> Can we clarify this statement?
> 
> Thanks
> Kiran
> 
> -- 
> Mops mailing list
> Mops@ietf.org
> https://www.ietf.org/mailman/listinfo/mops