Re: [httpstreaming] [conex] [dispatch] Q-HTTP

David Singer <> Wed, 10 November 2010 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14CEA3A68CD; Wed, 10 Nov 2010 05:01:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.524
X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z11NS5vIDG99; Wed, 10 Nov 2010 05:01:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4922A3A689B; Wed, 10 Nov 2010 05:01:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 239D3BBE7199; Wed, 10 Nov 2010 05:01:44 -0800 (PST)
X-AuditID: 11807137-b7bf7ae000000f05-35-4cda97b50e2a
Received: from [] (Unknown_Domain []) by (Apple SCV relay) with SMTP id 59.EA.03845.6B79ADC4; Wed, 10 Nov 2010 05:01:44 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: David Singer <>
In-Reply-To: <>
Date: Wed, 10 Nov 2010 14:01:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Roland Bless <>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAA==
Cc:, httpstreaming <>,, Ingemar Johansson S <>, "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" <>
Subject: Re: [httpstreaming] [conex] [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 13:01:29 -0000

Hi Roland,

On Nov 10, 2010, at 9:11 , Roland Bless wrote:

> Hi David,
> On 09.11.2010 11: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,
> QoS mechanisms are usually only necessary if you've got some kind of
> resource shortage. They try to manage the resource scarcity in some
> way then. So having "too much of a resource" seems to imply that we
> actually don't need any QoS support.

I think this raises a question that happens at a service provider.  Imagine I observe that my networks are getting more busy, and decide to invest some more in them.  Do I (a) deploy a QoS management infrastructure or (b) use those same funds to pay for capacity upgrades?  I think that most operators end up choosing (b) as it 'lifts all boats', whereas they are not confident that anyone will use (a) in the near future, and they know it won't benefit everyone (and in fact, will be to the detriment of some users who don't use it, and were previously doing 'fair competition' for bandwidth and now are 'second class' behind those with reserved bandwidth).

David Singer
Multimedia and Software Standards, Apple Inc.