Re: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01)

Qin Wu <sunseawq@huawei.com> Mon, 01 November 2010 07:54 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: httpstreaming@core3.amsl.com
Delivered-To: httpstreaming@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511DD3A6824 for <httpstreaming@core3.amsl.com>; Mon, 1 Nov 2010 00:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.982
X-Spam-Level: **
X-Spam-Status: No, score=2.982 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCPk4qrlZs79 for <httpstreaming@core3.amsl.com>; Mon, 1 Nov 2010 00:54:38 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BB7303A687E for <httpstreaming@ietf.org>; Mon, 1 Nov 2010 00:54:37 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB700MM04MRP3@szxga01-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 15:54:28 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB700F034MREQ@szxga01-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 15:54:27 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB7008ZF4MRUL@szxml06-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 15:54:27 +0800 (CST)
Date: Mon, 01 Nov 2010 15:54:27 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Mark Watson <watsonm@netflix.com>
Message-id: <00c201cb799a$01e83230$30298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
References: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> <F30F9206-7BE4-4A76-B2B4-91B0EE32FD62@nomor.de> <A0F798C3-2ECB-4150-8EC0-7A23118D057E@netflix.com> <02a801cb7715$bcd44e80$30298a0a@china.huawei.com> <1476B391-7FEF-453C-8351-DEC536B2FCD7@netflix.com>
Cc: httpstreaming@ietf.org
Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01)
X-BeenThere: httpstreaming@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming>
List-Post: <mailto:httpstreaming@ietf.org>
List-Help: <mailto:httpstreaming-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Nov 2010 07:54:39 -0000

Hi,
----- Original Message ----- 
From: "Mark Watson" <watsonm@netflix.com>
To: "Qin Wu" <sunseawq@huawei.com>
Cc: <httpstreaming@ietf.org>
Sent: Friday, October 29, 2010 12:30 PM
Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01)



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 ?

[Qin]: That's what I intepret from what you propose for efficient manifest delivery.
As you said, we may need to define new MIME type for manifest push, I agree. 
Futhermore, I think it will be a good idea to use such feature also for media stream efficient delivery when 
concurrent streams needs to be served by the same web server and the old chunk that has been playout and in aging conditions
need to be dropped.

The idea would be if the smart cache in between knows the semantics of new MIME type, this smart 
caches can choose to replace/update the previous chunk with the new chunk and
only serve the newest chunk to all the concurrent live streaming viewers.

For details, we may discuss this in Beijing meeting.

> We may need some new MIME subtype and new behaviors on how to process it.
> 
> ...Mark
> 
> 
> 
> 
> On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote:
> 
>> 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
>> 
>>> - I am not sure I understand the term "is encrypted into files"
>>> [ZN]: I mean "use file with media container" here.
>> 
>> [T]  I do not understand this either! [\T]
>> 
>>> - What do you mean "normal text file"?
>>> [ZN]: traditional web page (e.g. html file).
>> 
>> [T] we should be much more careful with terminology [\T]
>> 
>>> - The intelligence in the Adaptive Streaming over HTTP is almost
>>> exclusively in the client, there is no negotiation
>>> [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]
>> 
>>> 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?
>> 
>> [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]
>> 
>>> - 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?
>> 
>> [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 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.
>> 
>> [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]
>> 
>> 
>> ---
>> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || 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.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> httpstreaming mailing list
>> httpstreaming@ietf.org
>> https://www.ietf.org/mailman/listinfo/httpstreaming
>> 
> 
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming