Zaheduzzaman Sarker's Ballot Comments

[SpencerDawkins]

From @zaheduzzaman

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.

[SpencerDawkins]

@zaheduzzaman, thank you for the review. On a quick read (the authors have a conference call this afternoon my time), most of these are immediately actionable, and the ones that need a bit more discussion seem helpful and worth discussing.

More news to follow, of course.

[SpencerDawkins]

@GrumpyOldTroll and @acbegen - @zaheduzzaman's review has popped up some higher-level questions for me, that could be addressed in this issue, or in separate issues. I'm keeping this list here, until our call in about 26 minutes.

• This document uses the word "media" about 200 times, and the word "video" about 70 times. I know I haven't been careful to use the best word in text I've written. It's probably worth doing a pass in the document to make sure that we say what we mean. Actually, are we mostly talking about "media" in general, and only mentioning "video" in specifics?
• We only use the qualifier "high-bitrate" three times (and two of these are in the abstract and introduction). That seems like an important qualifier.
• I think this document does include Video On Demand. Does anyone disagree?
• We've been saying that media delivery over RTP is "out of scope", but the word "RTP" appears 12 times in the document. I think we're including "interactive", "live", and "VoD" streaming media, and we probably need to say that clearly, early in the document.
• is there any difference, from the media provider's perspective, if (presumably high-bitrate) media is streamed to be consumed by a machine?
• Zahed has an excellent question - can we explain what's different about ads, in about 1/4 the space?
• sometimes we say "content provider", and other times we say "media provider". Is there a meaningful difference, or can we use the same term?
• I'm surprised that we only use the term "operator" three times, and even more surprised that these aren't all talking about the same thing, so that needs to be fixed ...

[SpencerDawkins]

@GrumpyOldTroll and @acbegen - I'm working through the high-level questions in my previous comment, and I have a few new ones.

• We never defined "high-bitrate", although we (now) use the term in the abstract and in the Introduction. I'm thinking about adding a pointer to the table of typical bitrates for various bitrates and resolutions in the "Video Bitrates" section, and saying "like, these bitrates".

[SpencerDawkins]

@GrumpyOldTroll and @acbegen - @zaheduzzaman reasonably asked about a citation for this assertion in the draft:

In most real-world operating environments, wireless links can often experience sudden changes in capacity as the end user device moves from place to place or encounters new sources of interference. Microwave ovens, for example, can cause a throughput degradation in Wi-Fi of more than a factor of 2 while active [Micro]. 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.

After poking around for a while, I'm not seeing an obvious citation in open literature (indexed by Google), specific to 5G. We do need to decide what to do with this one comment, before merging #186.

[GrumpyOldTroll]

I probably wrote that text, and the reason I believed it was that it was discussed in I think a tsvwg or iccrg session talking about using chirping experimentally in conjunction with TCP Prague to find the link capacity, I think either by Ingemar or Bob. I now wish I could recall which meeting, or even which year I saw this.

I don't have a straight capacity metric, but I saw some stuff about attenuation and effects like shadow fading and path loss that I think are the physics reasons behind the 2nd-hand reported observation:

• https://ietresearch.onlinelibrary.wiley.com/doi/pdfdirect/10.1049/iet-com.2018.6016
• https://ieeexplore.ieee.org/abstract/document/7414036

Maybe we should strike the claim if we can't find a good source for it--these 5g docs talking about the relevant effects tend to speak in decibels rather than mbps, and it's not clear to me exactly how they translate.

[SpencerDawkins]

@GrumpyOldTroll -

Maybe we should strike the claim if we can't find a good source for it--these 5g docs talking about the relevant effects tend to speak in decibels rather than mbps, and it's not clear to me exactly how they translate.

I'd be astounded if no one at the IETF could speak to this, but in the references I could find, ISTM that there are all kinds of things that can affect pretty much any path traversing at least one wireless link. I removed the specific 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., which I don't think we can back up precisely, so now all the wireless-link paths are covered by an overarching In most real-world operating environments, wireless links can often experience sudden changes in capacity as the end user device moves from place to place or encounters new sources of interference.

If that works for you, #186 should be ready to review and (if it's OK) merge.

[SpencerDawkins]

@zaheduzzaman, on this comment,

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.

(as an aside, I should mention that I don't have any memory of active measurements being discussed in the working group for this document, but let's ignore that, for now, and try to do the right thing)

I couldn't think of a way to describe advantages of active testing that would work better than the measurement collection section for streaming media operators. Sure, active measurements can be the right thing to do, for operators providing access networks, etc.