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

[Qin Wu <[e-mail]>]

Hi, Thomas:
  ----- Original Message ----- 
  From: Thomas Stockhammer 
  To: Qin Wu 
  Cc: Daniel Park ; [e-mail] 
  Sent: Tuesday, September 28, 2010 1:58 PM
  Subject: Re: [httpstreaming] Discussion summarization in Dispatch on HTTP Streaming


  Dear Qin,


  you are absolutely right that 3GPP has exclusively and purposely focused on formats, that can be delivered through standard HTTP infrastructures (CDNs, HTTP servers, HTTP proxies, etc.). The specification focusses on describing the relationship and formats of "segments" and segments are resources that are made available to the client as http-URIs. This enables service providers to use these formats together with existing web cache infrastructures.


  There are many many good reasons for this and they had been discussed a year ago on the AVT mailing list when Apple submitted their draft. There were also opinions that RTP/UDP is good enough for streaming and streaming over HTTP is not the way to go.


  However, there is always a simple answer to why Adaptive Streaming over HTTP as today is justified and you have it in you e-mail below as well: "It works!" And maybe even more important: "It is heavily used"

  [Qin]: Yes, it work, does it work well? is it abusively used when you give more control to the browser client. I am wondering how could you make HTTP streaming controllable and managable by network operator and service provider? Is it really cheaper to deploy HTTP streaming into network since network is transparent to it and network operators do nothing? Are network operators really satisfying with this kind of existing approach?


  The decoupling of the video streaming application from a dedicated service and delivery infrastructure is what makes it so interesting. 
  If there is a general problem on how to massively scalable deliver data through HTTP, then this problem seem to be non-specific to streaming, isn't it? And please consider that there are ways to feed HTTP caches with protocols other than HTTP/1.1, such as FLUTE.

  [Qin]: No,current HTTP is it is originally designed to reliably transfer static contents like text documents, email, and HTML web pages. The requirement for efficient delievery through primarily come from streaming application which requires high QoS/QoE guanrateed, which current best effort Internet can not provide. Maybe there are other applications has the similar requirements like websocket application. 

  As for FLUTE, not sure they can fit for the real-time streaming requirement, e.g, handling thousands of concurrent streams simulatneously, flexible response to network congestion, high quality performance with low latency, packet loss, efficient bandwidth utilization.


  Best regards


  Thomas








  On Sep 28, 2010, at 7:08 AM, Qin Wu wrote:


    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: [e-mail]
      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 <[e-mail]>

        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
        [e-mail]
        https://www.ietf.org/mailman/listinfo/httpstreaming






    _______________________________________________
    httpstreaming mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/httpstreaming



  ---
  Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || 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.