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

Daniel Park <soohongp@gmail.com> Sat, 25 September 2010 07:33 UTC

Return-Path: <soohongp@gmail.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 D6AF43A6A4D for <httpstreaming@core3.amsl.com>; Sat, 25 Sep 2010 00:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.954
X-Spam-Level:
X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[AWL=-1.644, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6]
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 cvpC2IoDSw6I for <httpstreaming@core3.amsl.com>; Sat, 25 Sep 2010 00:33:17 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 392BA3A6A49 for <httpstreaming@ietf.org>; Sat, 25 Sep 2010 00:33:09 -0700 (PDT)
Received: by iwn3 with SMTP id 3so3512846iwn.31 for <httpstreaming@ietf.org>; Sat, 25 Sep 2010 00:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jFvfashpi+hI5LXxtLRImiwUITvC4PVLpACTtjny+/k=; b=cEkyX7RPdnbS4XQS7ah7u6pEVUTzP5KSTLU63tzm6wvL9ugOdSim38cr3mysIanU+U iX1h7loSzOF5kdsDdmnOMKjlCVaUW/QWurpAT2tegHijCSQce6hoLGx8Iaj5rKqSlyOT UkOQnzyJ/S5uDzd5ndvYKa0BIXTGyvsw0THwk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IK7A5Lsm6I+UTuecGihHHExKT8fE2e99ZVvgbaeR1VOQUGHPtutM5hxstnvQyJHbo+ Rw9jFBWOS89vHa44XeA93REmggijZP+wmAB7VpJdFrMuDn9+PmcYNF5WDWrSp4TZPEN/ qw6RAgdQ1o6PyYpnglP0Ntrb8Ia98HmEIEGRc=
MIME-Version: 1.0
Received: by 10.231.149.80 with SMTP id s16mr5184256ibv.81.1285400022414; Sat, 25 Sep 2010 00:33:42 -0700 (PDT)
Received: by 10.231.196.219 with HTTP; Sat, 25 Sep 2010 00:33:42 -0700 (PDT)
In-Reply-To: <02ed01cb5c65$a003d890$4f548a0a@china.huawei.com>
References: <000601cb59e8$f27af420$ff5afea9@C863D63E94E7457> <02ed01cb5c65$a003d890$4f548a0a@china.huawei.com>
Date: Sat, 25 Sep 2010 16:33:42 +0900
Message-ID: <AANLkTinkHikq2Cdh-7Xg83krE6M_j3swTaBYShe0P0sn@mail.gmail.com>
From: Daniel Park <soohongp@gmail.com>
To: Qin Wu <sunseawq@huawei.com>
Content-Type: multipart/alternative; boundary="0016e644df0abaf6780491108394"
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: Sat, 25 Sep 2010 07:33:20 -0000

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
>
>