Re: [httpstreaming] [dispatch] Q-HTTP

Lars Eggert <> Wed, 10 November 2010 02:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C6913A6910; Tue, 9 Nov 2010 18:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vKUeUmqAZm6L; Tue, 9 Nov 2010 18:02:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5590A3A68F8; Tue, 9 Nov 2010 18:02:08 -0800 (PST)
Received: from ( []) by (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAA22NSR019804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2010 04:02:24 +0200
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.4 at
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-60--337802050; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert <>
In-Reply-To: <>
Date: Wed, 10 Nov 2010 10:02:06 +0800
Message-Id: <>
References: <> <> <> <> <> <>
To: David Singer <>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (; Wed, 10 Nov 2010 04:02:13 +0200 (EET)
X-Nokia-AV: Clean
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: Wed, 10 Nov 2010 02:02:09 -0000

On 2010-11-9, at 18:31, David Singer wrote:
> 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.

Fully agreed. 

Folks who like pictures can take a look at, which gives much the same argument.