Re: [httpstreaming] [dispatch] Q-HTTP

David Singer <> Tue, 09 November 2010 11:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EF503A686A; Tue, 9 Nov 2010 03:45:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.449
X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Oe-j6D8dn0OI; Tue, 9 Nov 2010 03:45:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 15C4B3A6886; Tue, 9 Nov 2010 03:45:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 445B2B5D24E7; Tue, 9 Nov 2010 03:46:20 -0800 (PST)
X-AuditID: 11807134-b7c05ae000002d5d-f8-4cd9347e0bbf
Received: from [] (Unknown_Domain []) by (Apple SCV relay) with SMTP id 18.A0.11613.08439DC4; Tue, 9 Nov 2010 03:46:20 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: David Singer <>
In-Reply-To: <>
Date: Tue, 9 Nov 2010 12:46:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: =?iso-8859-1?Q?Gunnar_Heikkil=E4?= <gunnar.heikkila@ERICSSON.COM>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAA==
Cc: Ingemar Johansson S <>, "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" <>, httpstreaming <>, "" <>, "" <>
Subject: Re: [httpstreaming] [dispatch] Q-HTTP
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: Tue, 09 Nov 2010 11:45:57 -0000

On Nov 9, 2010, at 12:37 , Gunnar Heikkilä wrote:

> Hi David, Jose Javier,
> for cellular networks (for instance a PC using a mobile broadband dongle) over-provisioning is really expensive and you have to do something smarter. But I am not sure that the Q-HTTP concept is the way forward since it is based on injecting test traffic into the system. 

Right, but there is a choice of what the 'smarter' is.  (A) do some kind of QoS reservation (bandwidth reservation, maximum loss guarantee etc.) and then trust it; or (B) measure and adapt to what you're getting.

In case (A) if you are going to be resilient you should implement (B), so that if the reservation 'fails' you don't fail in turn. So you implement (B) anyway, and now the question is whether a new, special protocol for (A) is worth the trouble.  One huge downside is that it moves you away from generic servers, caches, proxies, CDNs and other existing network infrastructure.

In wireless, mobile, networks, it's hard to guarantee that the user won't move to the edge of a cell, or into a crowded cell where the reservation cannot be maintained, and so on.  Conversely, the 'cost' or availability of a reservation may well depend on the degree of competition.

David Singer
Multimedia and Software Standards, Apple Inc.