[Mops] Zaheduzzaman Sarker's No Objection on draft-ietf-mops-streaming-opcons-10: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-mops-streaming-opcons-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mops-streaming-opcons/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for working on this document. It has some details that is very useful to
read. Thanks to Michael Scharf for his TSVART review.

As instructed by my fellow AD to review this document as it is instead of
waiting for updates, I am doing it but I would like to see the TSVART review
addressed. The TSVART review has some very good comments.

Overall, by looking at the abstract of this document and the content of it, it
feels like it goes beyond "operational networking issues" or I felt to see in
some place what is the issue it conveys (I suggested an update see my comments
below).

Below I have some comments which I believe when addressed will improve the
document.

# Comments

## Abstract : the abstract should also say that this document is about both
networking and transport issues, as it does in the introduction.

## Section 1 :

  - "Streaming media" - does this covers both live streaming and VoD? this
  would be useful to convey in the beginning of this document.

  - it says "the server's transmission rate must (loosely or tightly) match to
  client's consumption rate in order to provide uninterrupted playback.", this
  might not be true if caching is involved. I realize the term "server" is a
  bit ambiguous here as it does not differ between a origin server and caching
  server at this point.

  - it says "the client's consumption rate is limited not only by bandwidth
  availability,but also media availability. The client cannot fetch media that
  is not available from a server yet." I would suggest to s/media/media
  segment(s). The media description file may be available but media segments
  might not, specially for live streaming media. and if the media is not
  available there is no consumption rate.

  - Minor comment - the beginning sentence in this section is way too long to
  read. I would suggest it to be split into several sentences.

## Section 2:

  - reference CVNI : can't read hence can't verify, seems like behind paywall,
  the URL leads to
  https://www.cisco.com/c/en/us/solutions/service-provider/index.html

  - I thought (from the introduction section) that unreliable media is out of
  scope of this document then I see some details will be provided later
  sections. I would not categorize unreliable RTP as a part of streaming media,
  even though streaming over RTP is a reality or did I misunderstood something?

## Section 3.1: I think it will be useful to add that

       - applications that use the video encoder can ask for lower bitrate
       encoding as the cost of video quality.

       - usually the video encoding does not take the available bandwidth into
       account.

       - for VoD case, the switching between the video bitrate depends on the
       available pre-encoded content at a particular bitrate.

## Section 3.2: AFAIK, the media player actually can detect the buffer
under-run and can ask the server to switch the bitrate up by selecting a higher
bitrate encoded media segment. I have not seen any mention of that in this
section, is this part of mitigation that is mentioned? if not then this section
is a bit incomplete capture the whole mechanism I am afraid.

## Section 3.7: I am confused about section 3.7 not sure what exactly to get
out of this section, specially what is the impact on network operation related
to streaming media.

## Section 4: the categorization of latency requirement will need a reference
if not the categorization is done and agreed in the WG.

## Section 5.4: if streaming of advertising and modulation quality uses same
technology as media streaming, then do we need to this long section for the Ad?
In the later part this section talks about ad fraud and mitigation for that
which I find completely application/player specific or integrated with
application. what is there for network OPS that is important in the context of
this document?

## Section 5.5.3: it says "5G and LTE likewise can easily see rate variation by
a factor of 2 or more over a span of seconds as users move around". Can we have
pointer to show some data supporting this, like we have the Micro? is the
because of the 5G and LTE technology itself or is this about network planning
issues?

## What about active measurements? it would be very useful to review them and
say why they are not relevant or not relevant for steaming media as part of
section 5.

## I would suggest to define the terms like media/content "producer" and
media/content "provider", or refer to where they are defined to be used in this
document. It is not that understandable from the text in this document. also
state the difference between media provider and content provider as both has
been used in this document.

## Section 6: I don't mind the transport protocol commentary :-), however, I
don't really see how the provided commentary actually achieves what the hanging
paragraphs in this section wanted to achieve. To me, it is possible that media
can be fetched from a server or a intermediary, and the media player metrics
collected to sense the observed media quality can be send to some other nodes
in the network. This means unless the media distributor and media provider are
same it will be hard to get a proper picture about the contention and fairness
(if that is really necessary and yes this adds to the point I made about
defining media provider and producer terms). The media application will have to
rely on the underlying transport protocol(s) for some sort of fairness among
the flows sharing same bottleneck, thats it. Yes, transport protocols will
evolve and the ware image and congestion control might change but the
fundamentals of transport services perhaps won't. To that extend I am kind of
with the INTDIR an TSVART reviewer's view.

## It seems like in the document only media consumed by human is considered,
there are other streaming cases where the media can be consumed by machines. If
later is out of scope then this need to be implicitly stated in this document.

## There has been more than one place where "we" is used. Even though I like to
read in active form of narratives in documents, here the use of "we" felt a bit
odd.