Re: [httpstreaming] Agenda and Slides

Ben Niven-Jenkins <> Thu, 11 November 2010 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17A3A3A6A69 for <>; Thu, 11 Nov 2010 08:33:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.299
X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d9BR38KHx7Nj for <>; Thu, 11 Nov 2010 08:33:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 245143A6822 for <>; Thu, 11 Nov 2010 08:33:56 -0800 (PST)
Received: from [] (helo=[]) by with esmtpa (Exim 4.71) (envelope-from <>) id 1PGa6S-00033d-VU; Thu, 11 Nov 2010 16:34:25 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Ben Niven-Jenkins <>
In-Reply-To: <>
Date: Thu, 11 Nov 2010 16:34:21 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <01df01cb8089$568d0b30$03a72190$> <> <> <> <> <>
To: David R Oran <>
X-Mailer: Apple Mail (2.1081)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: httpstreaming <>
Subject: Re: [httpstreaming] Agenda and Slides
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Nov 2010 16:33:57 -0000


Thank you, the extract of your e-mail that I have included below precisely describes my concerns with the httpstreaming drafts/proposal in a much more eloquent way than I could have expressed it myself.


On 11 Nov 2010, at 15:44, David R Oran wrote:
> Again, "not sure" isn't good enough. (I'm not sure if I might win the lottery). I don't think we've even gotten to step (1), which is demonstrating with real numbers and real measurements that there is a problem to be solved here. Then we need step (2) which is seeing if the problem has any feasible solutions that don't break other things, or overcomplicate the architecture. Then we can get to step (3) which is to compare the solutions against the baseline of doing nothing. At that point if enough improvement is demonstrated to warrant spending a lot of the IETF's time standardizing something, we can work on the details.
> My fear here is that we'll have a problem statement that boils down to "we need nano fiber transport cables to geosynchronous orbit" at one extreme, or "it sure would be nice if streaming HTTP made better use of scarce radio resources on 4G networks" at the other.
> I don't think the case has yet been made that there's a well-scoped problem for IETF to work on here. I heard somebody proposed that perhaps an IRTF research group ought to be the first step. That might be an alternative worth considering, but only if we can get the right people actually doing work (i.e. researchers with the right skill sets and resources to do the modeling, simulation, and experiments).