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

From: Ning Zong <[email-masked]>
Date: Mon, 25 Oct 2010 19:29:05 +0800

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:[email-masked]] 
Sent: Monday, October 25, 2010 6:47 PM
To: [email-masked]
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.

---

From: Thomas Stockhammer <[email-masked]>
Date: Tue, 26 Oct 2010 16:37:24 +0200

Experts,

Here are my initial comments:

Abstract:
- private -> proprietary

Introduction:
- The first sentence is messed, it mixes singular and plural
- The list of codecs, formats, players, platforms in the first  
sentence is quite arbitrary and more confusing than helpful
- 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
- 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.

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.
- 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.

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

On 5)
5.1)
- It would be good to fix the typos
- 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
- 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"
- What do you mean "normal text file"?
- The intelligence in the Adaptive Streaming over HTTP is almost  
exclusively in the client, there is no negotiation
- 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.
- 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.
- 3GPP defines QoE metrics that can reused also for HTTP Streaming.  
there will also be efforts in MPEG in including QoE.

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.

Best regards

Thomas

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

> <draft-zong-httpstreaming-gap- 
> analysis-01.txt>_______________________________________________
> httpstreaming mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpstreaming

---
Dr. Thomas Stockhammer (CEO) || [email-masked] || phone +49 89  
978980 02 || cell +491725702667 || 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.

---

From: Ning Zong <[email-masked]>
Date: Thu, 28 Oct 2010 13:57:15 +0800

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:[email-masked]] 
Sent: Tuesday, October 26, 2010 10:37 PM
To: Ning Zong
Cc: [email-masked]
Subject: Re: [httpstreaming] FW: New Version Notification for

Experts,

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
[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)
[ZN]: OK, thanks.
		for Media Segment: MIME Type is  vnd.3gpp.segment, file
extension  
[ZN]: Thank you.
[ZN]: I mean "use file with media container" here.
[ZN]: traditional web page (e.g. html file).
[ZN]: Sorry for confusion, "negotiation" should be "massage exchange".

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

---

---

From: Thomas Stockhammer <[email-masked]>
Date: Thu, 28 Oct 2010 08:51:00 +0200

Ning,

thanks ....

I recognized that you only replied to some of my comments.
Does this mean that you agree/disagree with the remaining ones?

Inline some more with [T] ... [\T]

Thomas

> [ZN]: I mean "use file with media container" here.

[T]  I do not understand this either! [\T]

> [ZN]: traditional web page (e.g. html file).

[T] we should be much more careful with terminology [\T]

> [ZN]: Sorry for confusion, "negotiation" should be "massage exchange".

[T]
First I hope this is a typo, otherwise I get more curious ...!
Secondly, I am still not clear what needs to be done beyond regular  
http connections
[\T]

> without experiencing the above mentioned "unforeseen" event or  

[T]
"Push" is a very very broad term. In Web applications you can for  
example use AJAX or RSS/ATOM like techniques for push-like updates. If  
you use conditional GET for regular polling, this is very efficient.  
The MPD updates in 3GPP work in a similar manner. If you use polling,  
conditional GETs and templates, you are extremely efficient. We should  
really understand what we mean by push model? HTTP-based delivery is  
rich and provides many successfully deployed options.

Should you really refer to something completely different such as IP  
multicast, then I would feel very very uncomfortable.
[\T]

> reasonable to request important packets for other channels. Did I

[T]
I would not be worried to have the MPD and the initialization segment  
of the two neighboring channels ready in my device. Again, the client  
can be very smart, especially as it does have access to all the  
information.

In general, I do not disagree that we can create more detailed use  
cases for environments in which we envision that HTTP streaming will  
be used. This may include live multi-channel environments. However, we  
should not conclude per se that the existing technologies do have a  
problem.
[\T]

> 3GPP/MPEG and cooperate with them to see how to capsulate the  

[T]
What do you mean with "capsulate"?
Also, can you be more specific what metrics there are in RTCP that can  
also be used in HTTP Streaming. I consider that anything dealing with  
packet loss is irrelevant. I also do not see the relevance of sending  
regular 5 seconds receiver reports as the content is static and  
adaptation will not happen. Some reporting on Media Presentation level  
may be sufficient, for example when the presentation has been completed.
[\T]

---

---

From: Mark Watson <[email-masked]>
Date: Thu, 28 Oct 2010 12:17:49 -0700

Here is an idea sparked by Thomas' mention below of AJAX and RSS push services.

In these services the client establishes a long-lived HTTP connection to a server on which it sends a single request. The response comes back in chunks, over time, enabling the server to "push" new content as it becomes available. Generally caches and proxies are transparent to this, although I think it does not work with some older proxies which expect to receive the whole response from upstream before returning anything to the client. Perhaps these are all gone by now. But anyway, the "chunks" cannot really be cached as the proxy has no idea what they are.

In the case of a document, such as a manifest, which is being periodically updated, or a sequence of different files, one could very simply expose these semantics in a standard way, which would enable caches to do their thing.

For example, suppose we define a new MIME type, multipart/versions, where each part of the multipart MIME response is a different version of the originally requested resource. A smart cache receiving a request for this resource can cache the "parts" as they arrive, each replacing the previously cached version. It can serve multiple incoming persistent connections with one upstream persistent connection, providing scalability. It would be transparent to existing caches. Clients would indicate their support in the Accept header and clients which did not support this mode would just poll the resource in the usual way with conditional GET requests.

All that would be required from a standards perspective would be definition of the multipart/versions MIME type.

Maybe this is not new. I could easily imagine CDNs do this kind of thing internally already.

Similarly, one could imagine a multipart/sequence MIME type where the parts form a sequence of objects. The client requests an object and (if it indicates support of the multipart/sequence MIME type) gets back that object and subsequent ones in the sequence (with their file names). Again, smart caches could optimise for scalability, caching the parts as separate objects. This could help with delivery of segments in the live case, but again maintaining backwards-compatibility. Again, perhaps CDNs already do something like this internally.

I'm not proposing to progress these ideas, just thought they were interesting.

...Mark

On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote:

> _______________________________________________

---

From: Qin Wu <[email-masked]>
Date: Fri, 29 Oct 2010 11:02:35 +0800

Hi, 
----- Original Message ----- 
From: "Mark Watson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 29, 2010 3:17 AM
Subject: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01)

[Qin]: Sounds like a good idea to me. I think this is one way to build the interoperable solution for concurrent live streaming viewing with backwards compability to existing cache and client, which may bring the advantage of alleviating server load.  But I am not sure the MIME subtype has the right semantic to do this. We may need some new MIME subtype and new behaviors on how to process it.

...Mark

---

From: "Severa, Michael J (Mike)" <[email-masked]>
Date: Thu, 28 Oct 2010 22:56:41 -0500

Hi. Check out server-sent events in HTML5. Essentially what is described here, though intended more for the application layer than the media layer. With a decoder interface at the application layer it would probably be possible to do this now by using that feature. 

Mike  
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Qin Wu [[email-masked]]
Sent: Thursday, October 28, 2010 8:02 PM
To: Mark Watson; [email-masked]
Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for      draft-zong-httpstreaming-gap-analysis-01)

Hi,
----- Original Message -----
From: "Mark Watson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 29, 2010 3:17 AM
Subject: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01)

...Mark

---

From: Mark Watson <[email-masked]>
Date: Thu, 28 Oct 2010 21:30:01 -0700

On Oct 28, 2010, at 8:02 PM, Qin Wu wrote:
> 
> [Qin]: Sounds like a good idea to me. I think this is one way to build the interoperable solution for concurrent live streaming viewing with backwards compability to existing cache and client, which may bring the advantage of alleviating server load.  But I am not sure the MIME subtype has the right semantic to do this.

[MW] Can you elaborate ?

> We may need some new MIME subtype and new behaviors on how to process it.
> 
> ...Mark
> 
> 
> 
>

---

From: Mark Watson <[email-masked]>
Date: Thu, 28 Oct 2010 21:32:20 -0700

Server-sent events defines a stream format for a sequence of DOM events. Essentially each is a set of name/value pairs. It's a very simple text syntax. Not really suitable for manifest updates or video stream segments. But mainly it does not carry any semantics that would enable cache optimizations.

...Mark