Re: [httpstreaming] [dispatch] Q-HTTP

Gunnar Heikkilä <> Tue, 09 November 2010 12:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 893AC3A68A6; Tue, 9 Nov 2010 04:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 564ok6jggbEb; Tue, 9 Nov 2010 04:04:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 601B53A686E; Tue, 9 Nov 2010 04:04:34 -0800 (PST)
X-AuditID: c1b4fb39-b7b54ae000003464-10-4cd938e9ae5c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9C.01.13412.9E839DC4; Tue, 9 Nov 2010 13:04:57 +0100 (CET)
Received: from ([]) by ([]) with mapi; Tue, 9 Nov 2010 13:04:56 +0100
From: =?iso-8859-1?Q?Gunnar_Heikkil=E4?= <>
To: David Singer <>
Date: Tue, 9 Nov 2010 13:04:56 +0100
Thread-Topic: [httpstreaming] [dispatch] Q-HTTP
Thread-Index: AcuAA72D1Oi/URn8T+SNPTHrIZ1PXQAAXG6Q
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>, httpstreaming <>, "" <>, Ingemar Johansson S <>, "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" <>
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 12:04:49 -0000

Hi David,

basically I agree with your view. My main point is that using extra traffic to solve bandwidth limitations has some built-in problems. Best would be if all applications could be made elastic and adapt to whatever problem they experience (like for AMR codec daptation etc.)...

Gunnar Heikkilä
Ericsson Research 

-----Original Message-----
From: David Singer [] 
Sent: ti 9 november 2010 12:46
To: Gunnar Heikkilä
Cc: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Ingemar Johansson S; httpstreaming;;
Subject: Re: [httpstreaming] [dispatch] Q-HTTP

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.