Re: [httpstreaming] [dispatch] Q-HTTP

Gunnar Heikkilä <> Tue, 09 November 2010 11:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01D693A6800; Tue, 9 Nov 2010 03:37:10 -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 qgYgrUEioHkJ; Tue, 9 Nov 2010 03:37:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 337CF3A672F; Tue, 9 Nov 2010 03:37:07 -0800 (PST)
X-AuditID: c1b4fb3d-b7b28ae00000135b-78-4cd9327b6373
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 00.20.04955.B7239DC4; Tue, 9 Nov 2010 12:37:31 +0100 (CET)
Received: from ([]) by ([]) with mapi; Tue, 9 Nov 2010 12:37:29 +0100
From: =?iso-8859-1?Q?Gunnar_Heikkil=E4?= <>
Date: Tue, 9 Nov 2010 12:37:28 +0100
Thread-Topic: [httpstreaming] [dispatch] Q-HTTP
Thread-Index: Act/+UPK/Ozu19IeQJie7DeY9Z/jewAAE0gw
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: Ingemar Johansson S <>, 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:37:10 -0000

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. 

Typically the wireless conditions can change rather fast (especially if the user is moving, say sitting on a train), so the "reaction time" based on the test traffic is most likley too long. The other problem is that the test traffic adds additional data into an already heavily loaded wireless network, which might not be easy to defend when selling this concept to the cellular operators.

But there is sure a need for good ways to handle the underlying problem you describe.

Best regards
   Gunnnar Heikkilä

-----Original Message-----
From: [] On Behalf Of David Singer
Sent: ti 9 november 2010 11:31
Cc: Ingemar Johansson S; httpstreaming;;
Subject: Re: [httpstreaming] [dispatch] Q-HTTP

There is a bitter lesson I have learned over the years to do with QoS reservation.

It is that there are two ways to solve a real-time bandwidth need.  One is to reserve bandwidth, manage QoS and so on;  one gets protocols and systems like diffserv, ATM, and so on.  The other is simply to have 'too much' of the resource.  Though it feels wrong, the latter often ends up being the cheaper and easier solution.  So, for example, voice over IP is getting used quite a lot, and to good effect, on the internet today not because we have successfully deployed any bandwidth reservation or QoS management protocols and systems, but because the available bandwidth is, for the most part, greatly in excess of what is needed, and the systems can adapt in real-time to what they get (rather than asking for what they want).  The same is true for multimedia delivery;  the complexity of RTP + TCP friendliness + QoS management is not worth it compared to having adaptable end-systems and overall more bandwidth than needed.

(I worked on real-time scheduling systems as well, and the same applies;  it's cheaper to have a processor which is much faster than needed, with a normal scheduler, than to have a just-enough processor with a real-time scheduler).

I know, it 'feels' wrong.

David Singer
Multimedia and Software Standards, Apple Inc.

httpstreaming mailing list