Re: [httpstreaming] FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01

[Ning Zong <[e-mail]>]

Hi, Thomas,

Thank you very much for your detailed review. I think the comments are also
very helpful for improving the draft. Please see my response in-line
starting with [ZN].

-----Original Message-----
From: Thomas Stockhammer [mailto:[e-mail]] 
Sent: Tuesday, October 26, 2010 10:37 PM
To: Ning Zong
Cc: [e-mail]
Subject: Re: [httpstreaming] FW: New Version Notification for
draft-zong-httpstreaming-gap-analysis-01

Experts,

Here are my initial comments:

Abstract:
- private -> proprietary
[ZN]: ok

Introduction:
- The first sentence is messed, it mixes singular and plural
[ZN]: OK, thanks.
- The list of codecs, formats, players, platforms in the first  
sentence is quite arbitrary and more confusing than helpful
[ZN]: I will clarify the text in next revision.
- Advantages on Adaptive Streaming over HTTP had been listed many  
times and a long time ago for example here:
	http://www.ietf.org/mail-archive/web/avt/current/msg11340.html
[ZN]: I will refer to this discussion in next revision.
- 3GPP defines formats for MPD and Segments, including the Media  
Segment Format. Client behaviour is informative
- The ISO/IEC JTC1/SC29/WG11 (MPEG) work has progressed significantly  
to a committee draft. The committee draft is heavily based on 3GPP AHS  
and has the same objectives, namely the definition of the formats for  
MPD and segments.
[ZN]: I will investigate more about recent progress on MPEG and OIPF work.

3.1 3GPP
- PSS is a stReaming services, it is hot, but not as hot as you make it.
- A significant amount of the text in 3.1. is just copied from the  
spec. It may be sufficient to point to the spec. It is public.
[ZN]: Right, but this part of the draft is purely survey and should mostly
rely on the reference. The analysis part is on Section 5. But anyway, I will
modify the text to simplify the copied text and add summary text when
needed, in the next revision.
- Some text in your document is sloppy, others is directly copied. I  
do not see any value to copy text as I said.

3.2 OIPF
- It is incorrect that your document introduces the extensions of the  
OIPF to 3GPP. The OIPF spec does this.
- The usage of normative text in your document seems inappropriate,  
like the "SHALL" in 3.2.2 and 3.2.3. Again, the OIPF spec is public  
and it is of no value to copy some text directly into this draft.
[ZN]: I will remove the normative term in next revision.

3.3 MPEG
- Again this is a pure copy of existing MPEG documents. A reference is  
sufficient.
- The information is outdated, as mentioned. Significant progress  
since MPEG#94
[ZN]: As noted, I will investigate more about recent progress on MPEG and
OIPF work.


On 5)
5.1)
- It would be good to fix the typos
[ZN]: OK, thanks.
- 3GPP segments and MPD are defined by their MIME Types. The statement  
in your table on file endings is wrong.
	Please refer to the specifications:
		for MPD: MIME Type is vnd.3gpp.mpd, file extension is .3gm
		for Media Segment: MIME Type is  vnd.3gpp.segment, file
extension  
is .3gs
[ZN]: Thank you.
- the steps in 1-3) are heavily simplified and this can only be an  
example. A client can act much differently, such as using byte ranges,  
parallel requests, etc. The server itself is also expected to be a CDN  
and is completely unaware of the contained media.
- I am not sure I understand the term "is encrypted into files"
[ZN]: I mean "use file with media container" here.
- What do you mean "normal text file"?
[ZN]: traditional web page (e.g. html file).
- The intelligence in the Adaptive Streaming over HTTP is almost  
exclusively in the client, there is no negotiation
[ZN]: Sorry for confusion, "negotiation" should be "massage exchange".
- The server software is typically considered standard HTTP/1.1, no  
specific intelligence. Some intelligence is needed in the preparation  
of the content, but this is typically no real-time process, at least  
for On-Demand video. Also for live "serving" and "preparation" are  
completely decoupled.

5.2)
- It is not correct that the 3GPP MPD needs to be updated even for  
live. If you use a template mode, the MPD stays static until some  
"unforeseen" event occurs. Client and Content Preparation have agreed  
on rules to construct URIs.
- If necessary, the MPD update happens asynchronously to the media  
decoding, so this is not considered to be a problem.
[ZN]: I didn't intend to state that pull model doesn't work. My point is,
why not investigating the possible usage of push model in certain cases
without experiencing the above mentioned "unforeseen" event or asynchronous
updates?
- I still heavily disagree with the push scenario as being viable.  
This assumes that there is a 1-1 relationship between the server and  
the client and the server is aware of the client's state. This is not  
in scope of any of the HTTP Streaming technologies that are referred  
to in your document. What you are proposing is more like advanced  
progressive download from dedicated servers. This had also been  
discussed in 3GPP, but is a different technology. It is server- 
enhanced progressive download and the client only issues a single HTTP  
request.
- There is for sure mechanisms to deliver important packets more  
reliably in HTTP - you just request it earlier. In anticipation of  
switching a smart client may also prepare such data. The client is  
intelligent.
[ZN]: Well, I think this startup issue doesn't like the pre-fetch which is
of course still valuable to improve playback. IMO, it is hard to predict
which channel the user will switch to in the next moment, hence it is not
reasonable to request important packets for other channels. Did I
misunderstand you?
- 3GPP defines QoE metrics that can reused also for HTTP Streaming.  
there will also be efforts in MPEG in including QoE.
[ZN]: I am not proposing to focus on defining QoE metrics, but looking on
the protocols to report such metrics, like RTCP. We will support the work in
3GPP/MPEG and cooperate with them to see how to capsulate the metrics in a
series of messages.

5.3)
- The No in QoE monitoring seems to be wrong, the same on fast start- 
up, see above!
- The other 'No's seem to assume a different model on delivery and we  
should really check, if this is still in the scope. It seems to  
address generic HTTP delivery issues, not streaming specific aspects.
[ZN]: OK, we will check them again and see which can be potentially
reasonable in our proposed work.

Best regards

Thomas




On Oct 25, 2010, at 1:29 PM, Ning Zong wrote:

> Hi, Folks,
>
> I have updated HTTP streaming survey and gap analysis draft and the  
> new
> version is as attached. You can also check the URL below:
> http://www.ietf.org/id/draft-zong-httpstreaming-gap-analysis-01.txt
>
> BR,
> Ning Zong
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[e-mail]]
> Sent: Monday, October 25, 2010 6:47 PM
> To: [e-mail]
> Subject: New Version Notification for
> draft-zong-httpstreaming-gap-analysis-01
>
>
> A new version of I-D, draft-zong-httpstreaming-gap-analysis-01.txt  
> has been
> successfully submitted by Ning Zong and posted to the IETF repository.
>
> Filename:	 draft-zong-httpstreaming-gap-analysis
> Revision:	 01
> Title:		 Survey and Gap Analysis for HTTP Streaming
Standards and
> Implementations
> Creation_date:	 2010-10-24
> WG ID:		 Independent Submission
> Number_of_pages: 23
>
> Abstract:
> With the explosive growth of the Internet usage and increasing demand
> for multimedia information on the web, media delivery over Internet
> attract substantial attention from media industry.  To meet above
> requirements, HTTP Streaming technology is designed and gradually
> plays an important role in recent years.  Several leading Standard
> Development Organizations (SDOs) have been producing a series of
> technical specifications to define streaming over HTTP.  Moreover,
> several companies have devoted to developing private HTTP-based media
> delivery platform to provide high quality, adaptive viewing
> experience to customers.  Following a brief survey of existing HTTP
> streaming standards and implementations, this document gives a brief
> summary on these related work, analyzes the potential challenges
> especially from the network point of view, and lists the gap between
> existing work and possible working scope on the topic of HTTP
> streaming in IETF.
>
>
>
>
> The IETF Secretariat.
>
> <draft-zong-httpstreaming-gap- 
> analysis-01.txt>_______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone +49 89  
978980 02 || cell [phone] || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München -  
Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 -  
Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.