Re: [httpstreaming] Discussion summarization in Dispatch on HTTP Streaming

Qin Wu <sunseawq@huawei.com> Tue, 28 September 2010 05:23 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 2FFF33A6C44 for <httpstreaming@core3.amsl.com>; Mon, 27 Sep 2010 22:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.228
X-Spam-Level: **
X-Spam-Status: No, score=2.228 tagged_above=-999 required=5 tests=[AWL=-1.678, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, 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 AR4ozvyEMuwI for <httpstreaming@core3.amsl.com>; Mon, 27 Sep 2010 22:23:00 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 409D13A6C3F for <httpstreaming@ietf.org>; Mon, 27 Sep 2010 22:22:58 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9F00HATYA39H@szxga04-in.huawei.com> for httpstreaming@ietf.org; Tue, 28 Sep 2010 13:08:28 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9F00CTGYA33C@szxga04-in.huawei.com> for httpstreaming@ietf.org; Tue, 28 Sep 2010 13:08:27 +0800 (CST)
Received: from w53375 ([10.138.84.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9F00D40YA37G@szxml06-in.huawei.com> for httpstreaming@ietf.org; Tue, 28 Sep 2010 13:08:27 +0800 (CST)
Date: Tue, 28 Sep 2010 13:08:26 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Daniel Park <soohongp@gmail.com>
Message-id: <02bd01cb5ecb$2f3e86b0$4f548a0a@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: multipart/alternative; boundary="Boundary_(ID_Ul8mH11TeIQhSrSN0dG+Jg)"
X-Priority: 3
X-MSMail-priority: Normal
References: <000601cb59e8$f27af420$ff5afea9@C863D63E94E7457> <02ed01cb5c65$a003d890$4f548a0a@china.huawei.com> <AANLkTinkHikq2Cdh-7Xg83krE6M_j3swTaBYShe0P0sn@mail.gmail.com>
Cc: httpstreaming@ietf.org
Subject: Re: [httpstreaming] Discussion summarization in Dispatch on HTTP Streaming
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: Tue, 28 Sep 2010 05:23:08 -0000

Hi, Daniel:
I agree it is a good idea to craft one gap analysis to compare different works in various SDOs than IETF.
Since we haven't done anything in IETF ,I am difficult to see any overlapping with other SDOs,:-).
Also in order to stimulate some discussion on this, I would like to share some of my views. In my personal opinion, It seems what other SDOs have standardized is very few. e.g., 
3GPP:
The only two components developed by 3GPP are Media presentation Description and one streaming media file format.
MPEG:
MPEG hasn't specified any solution for how to employ HTTP streaming to support MPEG Media except publishing Uses Cases and requirements for HTTP Streaming of MPEG Media
OIPF:
OIPF didn't specify anything except adoption of 3GPP approach.
Look at these works in 3GPP/MPEG, it seems they more rely on Browser Client to do many things, e.g., load/reload media presentation  description, control local playback, e.g., pause, resume by holding on segement request and reissuing segment request. What they require from network? Nothing. So what they are doing seems only to provide some component like Media presentation description and give some guideline on how to use this component
in HTTP streaming to support limited adaptive capability? For the browser client behavior and implentation, I think W3C is right place to standardize browser behavior. Is it enough? Is it efficient? Is it sufficient to support real time streaming?
In my opionin, these approaches developed by 3GPP more depend on existing infrastructure and pretty much easy to get some kind of service to market without any invest and effort from network provider and service provider. It works, But how to offer operators a more manageable and sustainable content services environment and, ultimately, lower costs is very painful and challenging.

Regards!
-Qin
  ----- Original Message ----- 
  From: Daniel Park 
  To: Qin Wu 
  Cc: httpstreaming@ietf.org 
  Sent: Saturday, September 25, 2010 3:33 PM
  Subject: Re: [httpstreaming] Discussion summarization in Dispatch on HTTP Streaming


  Good to see this activity within IETF and highly welcome.



  As you described below, there are already several SDO activities, and particularly they have their own direction and schedule toward the market. http-adaptive streaming (MS) and http-live streaming (Apple) are already implemented in the commercial level. 


  I believe, IETF should pay attention to the coordination among the existing activities/solutions, and particularly clarify the role for each in order not to make a duplication. Otherwise, this activity will be very confused in the market. Why ? It is because IETF rides in the train too late unfortunately.


  For doing that, gap analysis on the existing methods is the first, then we will be able to see which areas should be done by IETF based on the results of analysis. This direction seems very acceptable to me. 


  Anyway, I support, and hope to move it forward quickly.




  Daniel
  -- 
  Soohong Daniel Park
  http://www.soohongp.com




  2010/9/25 Qin Wu <sunseawq@huawei.com>

    Hi, folks:
    Glad to see this discussion list has been created with the support of all of you.
    Summarized what we discussed in the DISPATCH mailing list on HTTP Streaming, couples of things were well discussed:
    1. Does this work worth being done?
    Most of people speaked up on the list answer Yes since HTTP streaming is becoming more prevalent, large part of Internet Traffic today has been  possessed by HTTP Streaming, CDN and Direct Download.

    2. Is there any existing related work ongoing in IETF and other SDO? 
    This questions haven't been explicitly discussed. But I think it is necessary to bring out on the table since we need more input from these existing work
    and coordination between different group on the same topic is requried.

    So,Yes, we have lots of related work listed as follows:

    (a).IETF: 

    HTTP Streaming Problem Statement
    discuss the issues when delivering high quality contents to browser users.
    The related draft is available at:
    http://tools.ietf.org/html/draft-wu-http-streaming-optimization-ps-00

    Apples' HTTP live streaming: 
    well known for quite some time and implemented in the iPhone. It makes use of a M3U playlist file which serves as manifest and each media file must be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio elementary stream. 
    Movstreaming: is already deployed but also highly proprietary. However, it works with common media players. 
    The related work is avaiable at:
    http://tools.ietf.org/html/draft-pantos-http-live-streaming-04


    (b). IETF: Websocket protocol 
    Focus on browsing acceleration, devloped by Hybi WG,As one complementary work, W3C standardize websocket API

    (c).W3C' focus on client implentation bulit into browser,e.g., video playback support using script and html, push notification support using API, video support using Media fragments URI.

    (d).3GPPs' Adaptive HTTP Streaming (AHS): 
    introduced recently which defines a Media Presentation Description (MDP) 
    and extensions to the well known ISO Base Media File Format. 

    (e).Open IPTV Forum (OIPF): 
    has been published on Sep 7th, 2010 including "HTTP Adaptive Streaming" which adopts 3GPP AHS and adds support for MPEG-2 Transport Stream. The related work is available at:

    (f).MPEG' HTTP Streaming of MPEG Media : 
    MPEG has published Uses Cases for HTTP Streaming of MPEG Media and Requirements on HTTP Streaming of MPEG Media. The next stpe is to standardize a solution that addresses the need on how to employ HTTP Streaming to support MPEG MEdia.Therefore MPGE issued a call for proposals on HTTP streaming of MPEG media.

    Therefore Standardiztion related to this work needs to be carried out joint by IETF/W3C/3GPP . Overlapping work and efforts will be contributed to and synchronized 
    with these other relevant groups.


    3. Given various onging work in other SDOs than IETF and vairous different implementations developed by industries (e.g.,Apple, Microsoft, Adobe, RealNetwork), what contribution IETF could make?What's the potential work item? what kind of problem do we need to solve?

    Yes, it is clear IETF folks has expertise to do this work. The potential problems and issues the IETF folks are interested to look at and discuss are:
    (a). Issues involving real-time considerations and interoperability with other streaming techniques
    (b). Consideration of transportissues (fairness, delay, etc.)
    (c). Tweaking HTTP to improve streaming performance
    (d).Guidance on how to use HTTP in a network-friendly way.
    (e). Coordination with other protocols developed by IETF.
    (f). Offer better transport better than TCP (like SCTP), better tailored for the needs for streaming over http.
    (g). how to work in environments that may use a combination of RTP multicast and HTTP unicast.
    (h). How to deliver streaming contents to the client on any device with the same TV Quality of Experience.
    As for playlist format and streaming file format, these works have been specified by 3GPP, followed by MPEG/OIPF,probably not the interesting piece for the IETFers

    If I miss something or you have any further inputs and suggestions/comments, please speak up on the list.
    Based on these inputs and proposals, I would like to share our thoughts thus far on what  a new charter might
    look like and will post in a separate email to this discussion list. The feedback would be highly useful at this point.

    BTW:
    Since we have created separated mailing list for this topic, if you have any comments/ideas/proposals to share, please post
    them to the new discussion  list.

    Regards!
    -Qin




    _______________________________________________
    httpstreaming mailing list
    httpstreaming@ietf.org
    https://www.ietf.org/mailman/listinfo/httpstreaming