Re: [httpstreaming] Agenda and Slides

Qin Wu <> Wed, 10 November 2010 00:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4EF33A696C for <>; Tue, 9 Nov 2010 16:58:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.757
X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AKPsTcJoo+kc for <>; Tue, 9 Nov 2010 16:58:04 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id C64B53A6919 for <>; Tue, 9 Nov 2010 16:58:03 -0800 (PST)
Received: from (szxga05-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Wed, 10 Nov 2010 08:58:28 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Wed, 10 Nov 2010 08:58:28 +0800 (CST)
Received: from jys1037603 ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <>; Wed, 10 Nov 2010 08:58:27 +0800 (CST)
Date: Wed, 10 Nov 2010 08:58:39 +0800
From: Qin Wu <>
To: Mark Watson <>, httpstreaming <>
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <> <>
Subject: Re: [httpstreaming] Agenda and Slides
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Nov 2010 00:58:05 -0000

Thank you, Mark,we will take your comments into consideration at the meeting.

----- Original Message ----- 
From: "Mark Watson" <>
To: "httpstreaming" <>
Sent: Wednesday, November 10, 2010 4:39 AM
Subject: 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:
>> 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 mailing list