Re: [httpstreaming] Current Status and Our Goal

Ben Niven-Jenkins <> Thu, 30 September 2010 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C8363A6E1A for <>; Thu, 30 Sep 2010 10:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.245
X-Spam-Status: No, score=-103.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vhvWaAK-XjcG for <>; Thu, 30 Sep 2010 10:12:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7835A3A6DFD for <>; Thu, 30 Sep 2010 10:12:27 -0700 (PDT)
Received: from ([] by with esmtpa (Exim 4.71) (envelope-from <>) id 1P1Mgy-0001bs-Gd; Thu, 30 Sep 2010 18:13:12 +0100
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Ben Niven-Jenkins <>
In-Reply-To: <>
Date: Thu, 30 Sep 2010 18:13:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <00df01cb5de2$2ac49730$> <>
To: David A. Bryan <>
X-Mailer: Apple Mail (2.1081)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Subject: Re: [httpstreaming] Current Status and Our Goal
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, 30 Sep 2010 17:12:30 -0000

David, Colleagues,

On 29 Sep 2010, at 19:59, David A. Bryan wrote:

> So we have had a number of threads, some about possible work, some
> about details in the charter, etc. I think it is great to start
> thinking about a possible charter if this work turns into a WG, and
> some good reference drafts (thanks to Qin and the folks from Apple for
> putting these together), but I think another way to look at this might
> be to at least initially take a step back and see if the folks on the
> list can take a stab at some more basic questions. I think that was
> perhaps what Qin was getting at when we started this thread, but it is
> always good to refocus.

Ah! I (wrongly) assumed that the areas of possible work were already known to someone and the proposed charter was just an attempt to articulate them.

> I'll ask two really basic questions to the folks on list, and let's
> see what the opinions may be, and maybe we can move forward from
> there. Personally, I think that if we have a bar BoF, focusing just on
> these two basic questions (ok, one is a compound question, but one is
> basic!) might be a good way to move forward. I expect we'll have some
> VERY different answers. Remember that HTTP streaming may mean
> different things to people, and might even be the wrong term...but
> these are the things we need to try to figure out.
> 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?

I do not feel I am in a position just yet to start making statements about what problems I think a HTTP streaming group (if formed) should look at, however one area that I think may be interesting to study and that I am not aware of other bodies looking at is "chunk hints".

A lot of streaming media today is delivered via CDNs that operate as more than just a dumb (inline) proxy cache.

HTTP naturally supports the insertion of caches transparently to the end points so one could argue that nothing more needs to be done for HTTP streaming than for regular HTTP.

As adaptive bit rate combined with HTTP delivery relies on throughput measurements to determine the appropriate bit rate to download for subsequent chunks, variation in latency (e.g. the difference between a request for a chunk being a cache hit Vs a cache miss) is likely to affect the throughput perceived by the client and therefore may cause bit rate switch on a cache miss that wouldn't have occurred had the request actually been a cache hit.

If there was some way to provide a "hint" to the server/cache as to which chunk the client is likely to request next then a CDN could elect to retrieve that chunk ahead of it actually being requested to keep the response latency (or some other factor) more consistent and avoid additional bit rate switches.

> 2) What other standards body work in this space are you aware of
> (including IETF work), and how do you think any new work would fit in
> (or not!) with the answer above?

None that I am aware of.