[httpstreaming] Discussion summarization in Dispatch on HTTP Streaming

Qin Wu <sunseawq@huawei.com> Sat, 25 September 2010 03:56 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: httpstreaming@core3.amsl.com
Delivered-To: httpstreaming@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 0844A3A68BB; Fri, 24 Sep 2010 20:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.903
X-Spam-Level: **
X-Spam-Status: No, score=2.903 tagged_above=-999 required=5 tests=[AWL=-2.854, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3ikt21VlZRjc; Fri, 24 Sep 2010 20:55:59 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown []) by core3.amsl.com (Postfix) with ESMTP id D72603A6886; Fri, 24 Sep 2010 20:55:58 -0700 (PDT)
Received: from huawei.com (szxga05-in []) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9A009RJAY2GO@szxga05-in.huawei.com>; Sat, 25 Sep 2010 11:56:26 +0800 (CST)
Received: from huawei.com ([]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9A00BWDAY1CE@szxga05-in.huawei.com>; Sat, 25 Sep 2010 11:56:26 +0800 (CST)
Received: from w53375 ([]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9A001HTAY1A3@szxml04-in.huawei.com>; Sat, 25 Sep 2010 11:56:25 +0800 (CST)
Date: Sat, 25 Sep 2010 11:56:24 +0800
From: Qin Wu <sunseawq@huawei.com>
To: httpstreaming@ietf.org
Message-id: <02ed01cb5c65$a003d890$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_yssMswj13iWO0rUw1Lckkg)"
X-Priority: 3
X-MSMail-priority: Normal
References: <000601cb59e8$f27af420$ff5afea9@C863D63E94E7457>
Cc: dispatch@ietf.org
Subject: [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 03:56:01 -0000

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:


HTTP Streaming Problem Statement
discuss the issues when delivering high quality contents to browser users.
The related draft is available at:

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:

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

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.