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

Roland Bless <roland.bless@kit.edu> Wed, 10 November 2010 08:11 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: httpstreaming@core3.amsl.com
Delivered-To: httpstreaming@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA53C3A6A28; Wed, 10 Nov 2010 00:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVIsrtCTnOgy; Wed, 10 Nov 2010 00:11:26 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id A8B133A6A17; Wed, 10 Nov 2010 00:11:25 -0800 (PST)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PG5mF-0000yX-E6; Wed, 10 Nov 2010 09:11:37 +0100
Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PG5mF-0004ta-9w; Wed, 10 Nov 2010 09:11:31 +0100
Received: from vorta.tm.uka.de (i72vorta.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 3D4CD2FC046; Wed, 10 Nov 2010 09:11:31 +0100 (CET)
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.uka.de (Postfix) with ESMTPS id 1C9D7282; Wed, 10 Nov 2010 09:11:31 +0100 (CET)
Message-ID: <4CDA53B2.9000209@kit.edu>
Date: Wed, 10 Nov 2010 09:11:30 +0100
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: David Singer <singer@apple.com>
References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <DBB1DC060375D147AC43F310AD987DCC180E504600@ESESSCMS0366.eemea.ericsson.se> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <EAA2CFBF-9434-4E52-A586-7AE5F665A9DF@apple.com>
In-Reply-To: <EAA2CFBF-9434-4E52-A586-7AE5F665A9DF@apple.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1289376697.411569000
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: dispatch@ietf.org, httpstreaming <httpstreaming@ietf.org>, conex@ietf.org, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" <jose_javier.garcia_aranda@alcatel-lucent.com>
Subject: Re: [httpstreaming] [conex] [dispatch] Q-HTTP
X-BeenThere: httpstreaming@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming>
List-Post: <mailto:httpstreaming@ietf.org>
List-Help: <mailto:httpstreaming-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2010 08:11:29 -0000

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.

The basic problem is that even if you over-provision you'll depend
on the traffic distribution (i.e. the traffic matrix). For instance,
if you've got 10x100Mbit/s links aggregated to a 1 Gbit/s "upstream"
link, you usually have no problem of transmitting traffic towards the
larger link. In the other direction though, it depends heavily on the
incoming
traffic distribution. So if the 1 Gbit/s link transmits 200 Mbit/s
towards a single 100Mbit/s link over a longer period, you'll get dropped
packets. Denial-of-Service attacks can achieve this effect
intentionally. It's no problem using my PC and trying to flood several
DSL subscriber lines, or using 10 PCs at our campus site and trying to
flood some link with the aggregated bandwidth of ~ 10 Gbit/s. Your
real-time traffic will definitely suffer then...

I fear that the bandwidth demand will increase a lot due to HD streaming
etc. and that we need some kind of active QoS management at the edge
or access networks at least.

> the latter often ends up being the cheaper and easier solution.  So,

Yes, but not a really reliable solution and it works only as long as
the fair/whatever resource share is enough to provide the minimum
acceptable quality.

> 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 agree that having adaptable applications is a good idea anyway
and that QoS management adds a lot of complexity (and also complexity
at SLA level).

> (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.

I think it's fine as long as everything behaves somehow friendly,
i.e., in the absence of DoS flooding attacks...

Regards,
 Roland