Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt)

From: Ross Finlayson <[email-masked]>
Date: Wed, 1 Sep 2010 14:34:46 -0700

I agree that "HTTP streaming" should be standardized, and that the 
IETF appears to be the right place for this to be standardized.

Now, to be a little more provocative, here's an email that I sent to 
the "avt" and "mmusic" mailing lists back in June 2009, when the 
"pantos-http-live-streaming" draft was (briefly) discussed there.  I 
didn't get any responses to this back then, but there's definitely an 
"elephant in the room" here that can't be ignored.

>Date: Thu, 25 Jun 2009 03:56:51 -0700
>To: [email-masked], [email-masked]
>From: Ross Finlayson <[email-masked]>
>Subject: Re: [AVT] I-D Action:draft-pantos-http-live-streaming-01.txt
>
>I am pleased that Apple submitted this document as an Internet 
>Draft.  While I feel that much of the subsequent criticism has been 
>excessively harsh (or in some cases, misguided), I do agree with the 
>criticism that the document's title could be more descriptive.  The 
>current title - "HTTP Live Streaming" - suggests that it is a broad, 
>architectural overview document, which this really isn't.  A more 
>meaningful title for this document might be something like
>	"Using URI Playlist Files to Simulate Live Streaming"
>
>Nonetheless, if this approach is seen as being useful, then I would 
>like to see the IETF adopting and standardizing it (or something 
>similar), because both media streaming and transport protocols 
>(including HTTP/TCP - the transport protocol most commonly specified 
>within URIs) are clearly within the IETF's arena.
>
>However, this document focuses attention on a much bigger issue - a 
>proverbial "elephant in the room" - that at some point the IETF in 
>general, and the MMUSIC and AVT working groups in particular, are 
>going to have to address:
>
>Thanks to the ever increasing abundance of cheap mass storage, we 
>are now in a world where media consumption is increasingly 'on 
>demand' - e.g, via DVRs or online services like YouTube - rather 
>than live.  It seems inevitable that on-demand media playback will 
>dominate, with live media being relegated to relatively minor niches 
>where timeliness remains essential.
>
>Given this, we have to ask ourselves whether there is going to 
>continue to be a practical role for specialized protocols for live 
>media, or whether we will see more and more of the live media niches 
>being satisfied by hacks (like the one described by this draft) that 
>can make use of the increasingly dominant infrastructure that will 
>already be in place for on-demand media?  Telephony currently 
>remains a refuge for live media protocols, but how much beyond this 
>in the future?  (There are even companies out there now that are 
>providing videoconferencing over HTTP, within users' web browsers!)
>
>I believe that, at the very least, the IETF should try to be more 
>pragmatic about this (even if it means sometimes tarnishing 
>architectural purity).  To give just one specific example, I'm 
>disappointed that the IETF did not adopt and standardize Apple's 
>earlier mechanism (developed several years ago) for tunneling 
>RTSP/RTP over HTTP.  But given the points that I note above, I think 
>we're going to have to think hard about the future of RTSP in 
>general...

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Ning Zong <[email-masked]>
Date: Thu, 02 Sep 2010 09:07:56 +0800

Hi, Ross,
Thank you for your interests in HTTP streaming work.
I agree with the point about the title and scope of Pantos I-D, which
actually focus on a playlist file format and the corresponding usage in live
streaming. In my opinion, we could investigate more about the underlying
transport mechanisms for supporting such live streaming, e.g. HTTP/TCP,
which involves more WGs and energy in IETF. Please look at Qin's I-D
"draft-wu-http-streaming-optimizations-ps-00" for more discussion. Also, I
think that both Pantos I-D and Qin's I-D are good proposals in HTTP
streaming area, which shows that there is potentially a lot of interest and
more valuable input in this area if we focus these efforts in a closed
group.

My two cents,

BR,
Ning Zong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ross Finlayson
Sent: Thursday, September 02, 2010 5:35 AM
To: [email-masked]
Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D
Action:draft-wu-http-streaming-optimization-ps-00.txt)

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 2 Sep 2010 01:42:32 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ning Zong
> Sent: Thursday, September 02, 2010 4:08 AM
> To: 'Ross Finlayson'; [email-masked]
> Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt)
> 
> Hi, Ross,

OK, that is not explicitly mentioned in the Wu draft but let's assume it is a good idea for the time being. All the other SDOs I am aware of are staying away from these issues since they don't wanna mandate/require any changes in the transport to be able to run their specs in the current deployments. 

Personally, I would prefer a better transport scheme compared to HTTP over TCP, if I was allowed to make such changes. Neither TCP nor HTTP is crafted for this job.

> "draft-wu-http-streaming-optimizations-ps-00" for more discussion. Also, I

As I mentioned a month ago, this draft does not identify its goals clearly. It is like a review of the current status, which is already old by a few months :)

> more valuable input in this area if we focus these efforts in a closed

A playlist format spec is just one component. And that is probably not the interesting piece for the IETFers.

-acbegen

---

From: Ning Zong <[email-masked]>
Date: Thu, 02 Sep 2010 17:03:32 +0800

Hi, Ali
Glad to see your comments. Please see inline.

Regards
Ning Zong

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Thursday, September 02, 2010 4:43 PM
To: Ning Zong; Ross Finlayson; [email-masked]
Subject: RE: [dispatch] HTTP streaming WAS (Re: I-D

> transport mechanisms for supporting such live streaming, e.g. HTTP/TCP,

OK, that is not explicitly mentioned in the Wu draft but let's assume it is
a good idea for the time being. All the other SDOs I am aware of are staying
away from these issues since they don't wanna mandate/require any changes in
the transport to be able to run their specs in the current deployments. 

Personally, I would prefer a better transport scheme compared to HTTP over
TCP, if I was allowed to make such changes. Neither TCP nor HTTP is crafted
for this job.

[Ning Zong]: You are right. But I am suspect that changing HTTP or TCP or
their combination is easy job here. There has been a way between these 2
layers (like Web-socket) which is worthy of consideration for optimization
transportation of HTTP streaming.

> "draft-wu-http-streaming-optimizations-ps-00" for more discussion. Also, I

As I mentioned a month ago, this draft does not identify its goals clearly.
It is like a review of the current status, which is already old by a few
months :)

[Ning Zong]: Thank you for mentioning this. We will update the I-D.

> more valuable input in this area if we focus these efforts in a closed

A playlist format spec is just one component. And that is probably not the
interesting piece for the IETFers.

[Ning Zong]: Agree.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Thu, 02 Sep 2010 18:55:10 +0800

Hi,
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Ning Zong" <[email-masked]>; "Ross Finlayson" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 02, 2010 4:42 PM
Subject: Re: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt)
 
> OK, that is not explicitly mentioned in the Wu draft but let's assume it is a good idea for the time being. All the other SDOs I am aware of are staying away from these issues since they don't wann…

[Qin]: You are right, take a look at section 8.2 of draft-wu-http-streaming-optimization-ps-00, you will see HTTP over TCP is not optimal for real-time interactive media application.
How to enable efficient and QoS quaranteed communication on the Web is a big chanllenge to HTTP streaming. That's why we need more effort to optimize this transport.

> Personally, I would prefer a better transport scheme compared to HTTP over TCP, if I was allowed to make such changes. Neither TCP nor HTTP is crafted for this job.

[Qin]: I second this proposal and think it is feasible. Hybi set a good example to do this, which use websocket to provide  bi-directional, full-duplex communications channels over a single TCP socket.
BTW, would you like share your detailed view on how to provide better transport? :-)

> As I mentioned a month ago, this draft does not identify its goals clearly. It is like a review of the current status, which is already old by a few months :)

[Qin]: Thank for pointing this again, as I said, this I-D is still at the initial stage and waiting for update based on valuable input and feedback.

> A playlist format spec is just one component. And that is probably not the interesting piece for the IETFers.

[Qin]: I Agree that playlist format is only a component, actually there are lots of names for this component, e.g., index file, manifest, mpd.

Also depending on playlist as index and existing HTTP 1.1 as transport to request fragment by fragment seems only enable user to watch stream close
 to live and can not bring efficient communication as RTP/RTSP due to tranditional polling mechanism.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 2 Sep 2010 04:14:54 -0700

> From: Qin Wu [mailto:[email-masked]]
> Sent: Thursday, September 02, 2010 1:55 PM
> To: Ali C. Begen (abegen); Ning Zong; Ross Finlayson; [email-masked]
> > OK, that is not explicitly mentioned in the Wu draft but let's assume it is a good idea for the time being. All the other SDOs I
> am aware of are staying away from these issues since they don't wanna mandate/require any changes in the transport to be
> able to run their specs in the current deployments.
> 
> [Qin]: You are right, take a look at section 8.2 of draft-wu-http-streaming-optimization-ps-00, you will see HTTP over TCP is
> not optimal for real-time interactive media application.

Right, I was just stating a fact that probably everybody agrees with. But my concern is there is too much deployment in the field and the currently developed approaches are all refraining from making or requiring changes to the existing gear/stacks.

The question is whether it makes sense for any practical deployment, provider or owner to adopt the changes that IETF may produce. How much improvement do we need to make the new approach win? For marginal improvements, substantial hardware/software upgrade is not justified.

> How to enable efficient and QoS quaranteed communication on the Web is a big chanllenge to HTTP streaming. That's why
> we need more effort to optimize this transport.
> 
> > Personally, I would prefer a better transport scheme compared to HTTP over TCP, if I was allowed to make such changes.
> Neither TCP nor HTTP is crafted for this job.
> 
> [Qin]: I second this proposal and think it is feasible. Hybi set a good example to do this, which use websocket to provide  bi-
> directional, full-duplex communications channels over a single TCP socket.

That is for bidirectional traffic and streaming is not bidirectional. If you are consider doing videotelephony over HTTP, that is a different story and I would think we better separate it from streaming.

> BTW, would you like share your detailed view on how to provide better transport? :-)

Maybe something better than TCP (like SCTP), better tailored for the needs for streaming over http. This certainly would benefit from more discussion.
 
>  to live and can not bring efficient communication as RTP/RTSP due to tranditional polling mechanism.

Yes, it is inherently pull based, not push.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Fri, 03 Sep 2010 16:25:13 +0800

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Ning Zong" <[email-masked]>; "Ross Finlayson" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 02, 2010 7:14 PM
Subject: RE: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt)

[Qin]: This seems a big question. In my understanding,

With zero change to the existing gear/stacks:
1.Encoding live video for streaming over the Internet is extremely complicated and demands extensive CPU power. Therefore the current implementation may encourage the content publisher to reduce image quality, shrink the frame size, or force the user to experience long start/seek times so that the client-based player has time to buffer content. While these  improve the situation by reducing the volume of data sent or allowing the player to get ahead, the viewing experience is severely sacrificed. 

2. The current implentation may depend on multiple bit rates encoding to deliver the same content with different quality to clients however the cost of Multiple Bit rate encoding is very expensive, especially when streaming live video.

3. With the current implentation, client polling for playlist is okay, client polling for real time data fragment by fragment is not efficient way.

Given these above aspects, I am wondering whether the STB users or Mobile users are acceptable to the such playback experience when they watch program using browser, which may be far from TV viewing experience.Doesn't this worth improvement/optimization?

For how much improvment do we need to make the new approach win, we may look at this academic paper:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.62.574&rep=rep1&type=pdf

[Qin]: Agree.

[Qin] Sounds like a good idea. So the serious issues we may need to look at are:

How does HTTP Streaming support real time communication? How to enable migration of the real time application to Web? 

Any thoughts?

[Qin] Right.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 6 Sep 2010 01:40:49 -0700

> Sent: Friday, September 03, 2010 11:25 AM
> Right, I was just stating a fact that probably everybody agrees with. But my concern is there is too much deployment in the
> field and the currently developed approaches are all refraining from making or requiring changes to the existing gear/stacks.
> 
> The question is whether it makes sense for any practical deployment, provider or owner to adopt the changes that IETF may
> produce. How much improvement do we need to make the new approach win? For marginal improvements, substantial
> hardware/software upgrade is not justified.
> 
> 1.Encoding live video for streaming over the Internet is extremely complicated and demands extensive CPU power.

You mean encoding?

> Therefore the current implementation may encourage the content publisher to reduce image quality, shrink the frame size,
> or force the user to experience long start/seek times so that the client-based player has time to buffer content. While these
> improve the situation by reducing the volume of data sent or allowing the player to get ahead, the viewing experience is
> severely sacrificed.

I am not following what your proposal here is. Live encoding and streaming may pose additional challenges but they will naturally exist pretty much no matter what we have.
 
> 2. The current implentation may depend on multiple bit rates encoding to deliver the same content with different quality to
> clients however the cost of Multiple Bit rate encoding is very expensive, especially when streaming live video.

What is the alternative? SVC? On-the-fly transcoding?
 
> 3. With the current implentation, client polling for playlist is okay, client polling for real time data fragment by fragment is

Right, however, it won't be fragment by fragment for the updated manifests. There are certain so-called optimizations for this concern. For actual fragment download, it does not matter (much) whether the content is live or not as long as the caching system works reasonably OK.
 
> Given these above aspects, I am wondering whether the STB users or Mobile users are acceptable to the such playback
> experience when they watch program using browser, which may be far from TV viewing experience.Doesn't this worth
> improvement/optimization?

It could be. But, to start a work, we need better alternatives.
 
...
> How does HTTP Streaming support real time communication? How to enable migration of the real time application to Web?

I still think real-time communication is far different from streaming and we should not try to combine them.
 
-acbegen

---

From: Qin Wu <[email-masked]>
Date: Wed, 08 Sep 2010 12:48:06 +0800

Hi, Ali:
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Ning Zong" <[email-masked]>; "Ross Finlayson" <[email-masked]>; <[email-masked]>
Sent: Monday, September 06, 2010 4:40 PM
Subject: RE: [dispatch] HTTP streaming WAS (Re: I-DAction:draft-wu-http-streaming-optimization-ps-00.txt)

You mean encoding?

[Qin]: Yes, but I think Encoding is just one component we can make use of or resued.

[Qin]: Yes, we can not change encoding itself. But we may need to tune the video encoder algorithm to satisfy video quality
         requirements. we may need to determine which bitrate to use in a given situation
         and when to switch from one bitrate to another as bandwidth fluctuation.

         In some specific cases when the network is congested or saturated with  media traffic, how to downgrade the quality of content to adapt
         to transport capability, network condition is one possible way to solve this problem. when the network is back to normal, we also need to
         consider how to upgrade the quality of content.
         
        In the current implentation, we may use playlist/manifest to do this. But it is not flexible and also may cause too much starup time latency  and slow response
        by updating playlist. In this implentation, network and server do nothing since client controls the playlist updating.

 
[Qin] Yes, SVC is one alternative , like what I said in the ps draft.
         For on-the-flying transcoding, it is another choice, but I am afraid it is expensive and demand more power from CPU.
         Actually in the current implentation, they may also consider how to translate between differnt streaming file format, e.g.,
         translate from MP3 file to FLV file.becos different streaming may support different streaming file format.

[Qin]: Yes, manifest updating is only needed at the starup or switching. However manifest updating may cause starup latency or switching latency.
This latency may be not acceptable to the users who are accustomed to TV experience.

 
...

[Qin]: Agree. we may use real time streaming instead of real time communication.
 
-acbegen