Re: [httpstreaming] Agenda and Slides

All,

My apologies for not being able to attend tomorrow's meeting.

I took a look at the slides and have a few comments.

Overall, I am really concerned that the suggestions for problems and areas that need to be addressed are based on an incomplete understanding of how HTTP Streaming is working today and an incomplete analysis of the problems that do exist for real deployments of this technology. We really need a more complete analysis of the problems before jumping into solutions. "Problems" are frequently stated in the slides as "there is no support for X", where X is some feature. This is not a problem - this is a suggestion for a solution (feature X). We need to know what actual problems users and service providers see that are in scope of the IETF to look at, not just which new technologies people would like to look at.

Some specific comments on the Qin Wu slides:

Slide 4: I hope this is not really the goal of your meeting tomorrow ;-) Perhaps it is a proposal for a WG charter goal ? You should be very clear what is meant by "efficient" and what is meant by "transport". If you mean Transport Layer, say that. Overall the goals are too high-level: noone could disagree that subscriber QoE requirements should be met (if they are indeed requirements this is tautological).

Slide 5:
- I'm not sure I agree with the definition. Yes, streaming is characterized by a timing relationship between delivery and rendering, but this doesn't imply "steady and continuous"
- The use of chunks has very little to do with "large packet dropout rate due to TCP", whatever that is.

Slide 6:
- The motivations for HTTP streaming on this slide are completely wrong. HTTP Streaming is popular (1) because it is based on re-use of existing web infrastructure which is successfully operating at Internet scale and (2) because of the possibility for real-time adaptation (to network conditions, but also device capabilities and user preferences). Device capabilities could be incorporated in the "multi-screen" point, but is nevertheless secondary. It has almost nothing to do with browser support - many HTTP streaming solutions do not use the same HTTP stack as the browser anyway.

Slide 7:
- It would be nice to mention the largest HTTP streaming service in terms of hours viewed (Netflix). Especially as we are very much involved in standardization efforts. 

Slide 9&10:
- You should note here that "chunks" are not necessarily separate files on the web server, but may be identified by byte ranges or other means.

Slide 11:
- I'm not buying that HTTP delivery is especially "inefficient". Compared to what ? I think you need to quantify the inefficiency - at least back-of-envelope - to state this as a "problem".
- I don't understand the first bullet
- The second bullet seems to be issues with procedures, rather than protocols

Slide 12:
- I disagree that there are no techniques using the existing protocols that can improve QoE - we are doing this all the time ;-)
- "Best effort internet" - I agree with the sub-bullet, but I am not sure what this has to do with "best effort" - if there is insufficient capacity then there is insufficient capacity. Slicing and dicing it just moves the problem.
- Standards for QoE reporting would be useful. We proposed this in MPEG. I disagree that this is more difficult in the client pull model. Our clients provide us with copious information which is much easier to manage than server logs would be (because it is the client which has a notion of "session" to report on). Only the client knows what the user actually saw.
- I don't know why you would continually update the manifest. I know some systems do this for live, but it still seems unnecessary to me.

Slide 14:
- As I mentioned in email, it's not clear to me that HTTP streaming traffic should be prioritized over web traffic. But anyway, I think you are addressing the issue the wrong way around. The question should be: given a particular profile of available bandwidth, how do I deliver the best possible service to the user ? If, in some environment, that profile is guaranteed to be constant high data rate, by some prioritization or QoS mechanism, then great. But in other envionments that is not the case and we still need to deliver service.

Slide 15:
- I don't understand this one at all. The possibility to use existing distributed web infrastructure and caching is exactly the primary motivation for HTTP Streaming. CDNs do a lot of things already that make their systems work efficiently. Is the proposal that we standardize how CDNs work ? Should we have some CDN representatives present before embarking on that ?

...Mark

On Nov 6, 2010, at 11:37 PM, David A. Bryan wrote:

> I just uploaded an agenda and the current slides from the
> participants. The slides are available as links from the agenda, which
> I have uploaded here:
> 
> http://www.p2psip.org/httpstream/79/Agenda.html
> 
> I still don't know which room is the IESG room, but I will find out
> and post here shortly.
> 
> Thanks, and see you all on Wed.
> 
> David
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 