Re: [httpstreaming] Current Status and Our Goal

Colin Perkins <csp@csperkins.org> Thu, 07 October 2010 11:16 UTC

Return-Path: <csp@csperkins.org>
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 AA0583A70D4 for <httpstreaming@core3.amsl.com>; Thu, 7 Oct 2010 04:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.376
X-Spam-Level:
X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 OL7H412zxudd for <httpstreaming@core3.amsl.com>; Thu, 7 Oct 2010 04:16:05 -0700 (PDT)
Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id 89E993A721D for <httpstreaming@ietf.org>; Thu, 7 Oct 2010 04:15:59 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P3oT6-0001m6-gN; Thu, 07 Oct 2010 11:17:00 +0000
Message-Id: <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org>
From: Colin Perkins <csp@csperkins.org>
To: Roni Even <Even.roni@huawei.com>
In-Reply-To: <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 07 Oct 2010 12:16:58 +0100
References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com>
X-Mailer: Apple Mail (2.936)
Cc: httpstreaming@ietf.org
Subject: Re: [httpstreaming] Current Status and Our Goal
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: Thu, 07 Oct 2010 11:16:09 -0000

On 6 Oct 2010, at 22:56, Roni Even wrote:
> I think that David first question is important and here is my view
>
> Roni Even
>
>> So the two big questions:
>>
>> 1) On the topic of this list/HTTP streaming, what do you think is the
>> problem/problems/scenario we should be looking at?
>
> My view is that we are trying to address the transport of media in  
> HTTP both pre-recorded and live. The major issues I see are
>
> 1. Address the issue of allowing both push and pull models  
> (addressing the use cases and concerns from Qin draft)
> 2. Address the startup issue, we have worked in AVT on fast channel/ 
> content change and I think this is relevant also in this case.
> 3. Look at the scaling problem when there is no multicast or broadcast
> support.
>
> In general I think that by having a use cases document that covers the
> scenarios that look important to the group we can achieve a better
> understanding of what is the charter of the work.


There are clearly some issues to consider here. What seems to be  
missing from the discussion to me though, is some identification of  
the concrete problems. What protocol pieces do we need, but not have?  
What protocols are problematic, and need enhancement? Is there  
protocol work to do in IETF, or should we be documenting best current  
practices for using the existing protocols and/or relying on other  
bodies to fill the gaps?

The draft-wu-http-streaming-optimization-ps is a good start at such an  
analysis, but doesn't go deep enough to let us decide what work IETF  
should do.

-- 
Colin Perkins
http://csperkins.org/