Re: [httpstreaming] Current Status and Our Goal

[Wenbo Zhu <[e-mail]>]

Seems we are starting to talk about very specific issues here.
Probably a good idea to start a separate thread, with the existing
arguments summarized?

On Thu, Oct 14, 2010 at 8:22 PM, Qin Wu <[e-mail]> wrote:
> 
> I respect your opionion although I can't agree with you. I would like to
> hear what other people thinks. Thanks!
>
> ----- Original Message -----
> From: Mark Watson
> To: Qin Wu
> Cc: Ali C. Begen (abegen) ; [e-mail] ; Colin Perkins
> Sent: Friday, October 15, 2010 12:26 AM
> Subject: Re: [httpstreaming] Current Status and Our Goal
>
> On Oct 14, 2010, at 2:41 PM, Qin Wu wrote:
>
> Hi,
>
> ----- Original Message -----
> From: Mark Watson
> To: Qin Wu
> Cc: Ali C. Begen (abegen) ; [e-mail] ; Colin Perkins
> Sent: Tuesday, October 12, 2010 12:50 AM
> Subject: Re: [httpstreaming] Current Status and Our Goal
> Some comments online ...
>
> Sent from my iPhone
> On Oct 11, 2010, at 7:50 PM, "Qin Wu" <[e-mail]> wrote:
>
> Hi,
> This is what we had discussed  in the DISPATCH mailing list before we move
> to this discuss list.
> If you look at the description of discuss list, "
> offers more efficient transport
> and better network capability for real time streaming media
> and allows interoperability with other streaming techniques and existing
> Progressive dowloaded based
> HTTP streaming implementation.
> "
> you will see we are on the same page.
> Therefore one important goal discussed in the draft aims at developing
> interoperable solution to
> provide better transport to satisfy the real time streaming QOE requirement.
> Especially serveral
> chanllenges/problems we explored in the draft listed below.
>
> Regards!
> -Qin
>
> ----- Original Message -----
> From: Mark Watson
> To: Ali C. Begen (abegen)
> Cc: [e-mail] ; Colin Perkins
> Sent: Sunday, October 10, 2010 7:13 AM
> Subject: Re: [httpstreaming] Current Status and Our Goal
> All,
> I would like to add my support to the comments below. Specifically, I think
> if the IETF considers work in this area it should focus on the HTTP and TCP
> protocols. Any such work may not be specific to HTTP-streaming (i.e.
> enhancements that are at first motivated by HTTP Streaming may have broader
> applicability, and this should be carefully considered).
> In the draft I do not see a clear or correct identification of the problems.
> For example in the introduction the following are stated as issues:
>
>    - Client polling for each new data in chunks using HTTP requests is
>    not efficient to deliver high-quality video content across the
>    Internet
>
> MW: Several companies, including my employer, are successfully operating
> large scale HTTP streaming systems that do efficiently deliver high-quality
> video content across the Internet, so reality seems to refute this
> statement.
>
> [Qin]: Not sure they can provide the TV experience for all the connected
> devices like smartphones, PCs and tablets. Also not sure they can provide
> the same quality of experence for all the all the connected devices. As we
> discussed in this thread, a minimum of 20 seconds to start your video often
> frustrated users to keep on watching and provide very limited user
> experience.
>
> Can you be more explicit about the problems that you see? I'm not sure where
> the 20s figure comes from. I do not see any problem in supporting startup
> times comparable to TV channel change with adaptive HTTP streaming.
> I am not saying there is no room for improvement in the various deployed
> systems, but I do not see major technical impediments to efficient delivery
> of high quality video using HTTP Streaming.
>
> [Qin]:Not only starup latency but also delay w.r.t. real time streaming. I
> think you negect it becos You didn't get into the discussion list.
>
> On the other hand, I think we should bear in mind HTTP is formerly designed
> for browsing webpage, transport static contents like HTML page, plugin,
> picture, when we are going to use HTTP to deliver real time streaming
> contents, we can not expect to get higher user experience. Therefore the
> current streaming schemes can only offer a better experience over slower
> connections.
>
>    - Segmentation capability requires over-utilizing CPU and bandwidth
>    resources, which may not be a desirable and effective way to improve
>    the quality of streaming media delivery
>
> MW: It is not clear that segmentation per se is CPU-intensive or has any
> non-negligable effect on bandwidth usage.
>
> [Qin]: Since HTTP streaming server is the combination of streaming server
> and regular web server, I think the answer is both.
>
> [MW] what do you mean by' http streaming server' ?
>
> [Qin]: With streaming capability and functionality to respond to HTTP
> connection.
>
> [MW] I'm not sure what one of those is. It sounds like it is not a regular
> web server. I think it's an essential feature of modern HTTP streaming that
> it works with regular web infrastructure.
>
>    - Lack of QoS guarantee on the packet switching based Internet , the
>    quality of Internet media streaming may significant degrade due to
>    rising usage
>
> MW: An alternative view is that where quality is degraded due to congestion
> this is due to lack of bandwidth, rather than a lack of QoS guarantees.
> Adaptive HTTP streaming systems adjust the video quality to the available
> bandwidth in order to avoid rebuffering events. It is the available
> bandwidth that needs to be improved to improve quality.
>
> [Qin]: What I emphasize here is with growing popularity of HTTP streaming
> traffic, when thousands or millions of people are accessing the same media
> contents, the big problem we are facing is serious high concurrence access
> issue. The user experience will be greatly affected even you have enough
> available bandwidth. So this is not pure bandwidth issue.
>
> [MW] maybe we mean different things by 'available bandwidth'. Do you think
> it is a server scalability problem, or a network problem ?
>
> [Qin]: please
> read http://www.ietf.org/mail-archive/web/httpstreaming/current/msg00011.html
>
> [MW] Still not sure what you're referring to other than available bandwidth.
> The thread mentions multicast - do you think there remains work to deliver
> HTTP objects over multicast given the work in RMT over the years ?
>
>    - Experience burstiness or other dynamics changes due to bandwidth
>    fluctuations and heterogeneous handover.
>
> MW: We have found that adaptive HTTP streaming algorithms are well able to
> cope with bandwidth fluctuations.
>
> [Qin]: I don't doubt that adaptive HTTP streaming algorithms can cope with
> bandwidth fluctation. But I hope we can do better.e.g., adaptive HTTP
> streaming algorithms only support delivery of multiple streams of the same
> content with varying quality levels for different bandwidth or devices.
> Howeve how the server in push model or client in pull model can quick
> response to the bitrate changes is a problem we may look at,especially when
> switching beween streams occurs very frequently.
>
> [MW] Yes, but not a problem for the IETF, I think.
>
> [Qin]: I didn't get what you said. adaptive HTTP streaming algorithms is
> characterized as  client initiated pull model. We are discussing push model
> or how to use pull model with push model.We are talking about different
> model. There are plenty room for IETF to do for this.
>
> [MW] Sorry, I don't understand what the "push" model has to do with HTTP
> Streaming. Are you talking about servers which are not regular HTTP servers
> ? I think this is not what people usually mean when they say "HTTP
> streaming" - you should rename the work if that is the case.
>
>    - Impossible to fast-forward through any part of a streaming
>    contents until it is stored on the user's device
>
> MW: This is simply not correct, since there are hundreds of examples of
> devices which support trick-play using HTTP streaming techniques without
> storing the whole content on the users device.
>
> [Qin]: Fast forward capabilty is not the most important feature we are
> looking for. However I am hard to believe existing HTTP streaming techniques
> can provide the same degree of playbackcontrol that DVD player can provides
> or RTSP protocol provides. E.g., In the adaptive HTTP streaming algorithms,
> the trick play is limited to pause/resume/stop by driving the HTTP request.
> If the contents hasn't been dowloaded and the consume want fast forward, the
> HTTP client needs to issue another new HTTP request to fetch the contents
> which willcause unacceptable latency to the consumer.
>
> [MW] Again, the experience of millions of existing customers refutes what
> you claim. Why do you think it is necessarily so slow to issue a new HTTP
> request for a different part of the content?
>
> [Qin]: You didn't see the reaon behind this, becos the existing customers
> has no choice when they view live streaming, what they can get is close to
> live experience rather than real time user experience. Operatoer do nothing
> for their network to make http streaming more controllable and managable.
> Therefore more and more consumer tend to choose non-live content. that's why
> we see more and more non-live content consumers rather than live contents
> consumers.
>
> [MW] Well, I'm not sure I understand the point. But still the statement in
> the draft is not true.
> ...Mark
>
> A first step in considering what, if any, work should be done here might be
> to contact those organizations which are standardizing the higher layers of
> HTTP streaming systems (e.g. manifest and file formats) and ask whether
> there are deficiencies they see in IETF protocols that could be usefully
> addressed by the IETF. What I think we should avoid in the IETF is
> duplicating the work of these other bodies.
>
> Best,
>
> Mark Watson
>
> Netflix Inc.
>
>
>
> On Oct 10, 2010, at 12:43 AM, Ali C. Begen (abegen) wrote:
>
>
> -----Original Message-----
>
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Lars Eggert
>
> Sent: Friday, October 08, 2010 4:17 PM
>
> To: Colin Perkins
>
> Cc: [e-mail]
>
> Subject: Re: [httpstreaming] Current Status and Our Goal
>
> On 2010-10-7, at 14:16, Colin Perkins wrote:
>
> There are clearly some issues to consider here. What seems to be
>
> missing from the discussion to me though, is some identification of
>
> the concrete problems. What protocol pieces do we need, but not have?
>
> What protocols are problematic, and need enhancement? Is there
>
> protocol work to do in IETF, or should we be documenting best current
>
> practices for using the existing protocols and/or relying on other
>
> bodies to fill the gaps?
>
> The draft-wu-http-streaming-optimization-ps is a good start at such an
>
> analysis, but doesn't go deep enough to let us decide what work IETF
>
> should do.
>
> +1
>
> The key question really is "what do you think the IETF needs to do?"
>
> I imagine the only work the IETF should do (if we decide to) is the
> transport and HTTP-layer optimization for better streaming performance.
>
> -acbegen
>
> Lars
>
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming
>
>
>
> ________________________________
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming
>
>
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming
>
>