Re: [httpstreaming] [dispatch] Q-HTTP

"Mike Hammer (hmmr)" <> Tue, 09 November 2010 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67F8D3A683A; Tue, 9 Nov 2010 07:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5+XcZ+7-nZn6; Tue, 9 Nov 2010 07:37:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 43DE63A688F; Tue, 9 Nov 2010 07:37:18 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALf42EytJV2Y/2dsb2JhbACiInGjbptlhUoEhFmJDw
X-IronPort-AV: E=Sophos;i="4.59,174,1288569600"; d="scan'208";a="180222798"
Received: from ([]) by with ESMTP; 09 Nov 2010 15:37:42 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id oA9Fbg3B030397; Tue, 9 Nov 2010 15:37:42 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 09:37:42 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 9 Nov 2010 09:37:40 -0600
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [dispatch] [httpstreaming] Q-HTTP
Thread-Index: Act/+UlpMMdCwOPNTv+dYC+XcynYvwAKevGw
References: <><><><><> <>
From: "Mike Hammer (hmmr)" <>
X-OriginalArrivalTime: 09 Nov 2010 15:37:42.0274 (UTC) FILETIME=[0C3DB620:01CB8024]
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
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 15:37:21 -0000


Video has much more volume and burstiness than VoIP, so not sure that
analogy will hold.  If you cannot be sure to have at least 50%
non-latency-sensitive traffic, and maybe more like 70%, then you will
not be over-provisioned enough to have the slack available.  And if
video is the lion's share of the traffic, then you better hope that most
of that is non-interactive.  Else, you need some type of CAC to ensure
live video doesn't get disrupted.

Separate question.  Took a quick read and it seems this Q-HTTP is a
separate flow rather than embedded attributes in the flow it is
attempting to help.  What if there is more than one flow involved?  And
how do you keep each control and app associated?


-----Original Message-----
From: [] On
Behalf Of David Singer
Sent: Tuesday, November 09, 2010 5:31 AM
Cc: Ingemar Johansson S; httpstreaming;;
Subject: Re: [dispatch] [httpstreaming] Q-HTTP

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

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.

dispatch mailing list