Re: [httpstreaming] [dispatch] Q-HTTP

David Singer <> Tue, 09 November 2010 10:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98A213A6946; Tue, 9 Nov 2010 02:30:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ahm7nC6WUrFA; Tue, 9 Nov 2010 02:30:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F21143A6849; Tue, 9 Nov 2010 02:30:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8A916BB93DEC; Tue, 9 Nov 2010 02:31:07 -0800 (PST)
X-AuditID: 1180711d-b7c86ae000000247-e8-4cd922e69d1f
Received: from [] (Unknown_Domain []) by (Apple SCV relay) with SMTP id 38.DD.00583.7E229DC4; Tue, 9 Nov 2010 02:31:07 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: David Singer <>
In-Reply-To: <>
Date: Tue, 9 Nov 2010 11:31:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.1081)
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 10:30:53 -0000

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.