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

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Tue, 16 November 2010 16:47 UTC

Return-Path: <ben@niven-jenkins.co.uk>
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 1CB833A6B69; Tue, 16 Nov 2010 08:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.681
X-Spam-Level:
X-Spam-Status: No, score=-103.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 CTTcmZeD1CKN; Tue, 16 Nov 2010 08:47:31 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by core3.amsl.com (Postfix) with ESMTP id 305E43A68F2; Tue, 16 Nov 2010 08:47:31 -0800 (PST)
Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1PIOha-0007HL-2j; Tue, 16 Nov 2010 16:48:14 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
In-Reply-To: <alpine.DEB.1.10.1011102303170.2639@uplift.swm.pp.se>
Date: Tue, 16 Nov 2010 16:48:12 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <A86F69B7-1A6A-4D58-BBD2-2D97CB8FA4F8@niven-jenkins.co.uk>
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> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <C4064AF1C9EC1F40868C033DB94958C7031F0C1F@XMB-RCD-111.cisco.com> <EF84DC37-8CB6-4DB7-85AC-E091D90FF075@apple.com> <C4064AF1C9EC1F40868C033DB94958C7031F0CA2@XMB-RCD-111.cisco.com> <alpine.DEB.1.10.1011102303170.2639@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.1081)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: dispatch@ietf.org, httpstreaming <httpstreaming@ietf.org>, conex@ietf.org, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "Mike Hammer \(hmmr\)" <hmmr@cisco.com>, "GARCIA ARANDA, JOSEJAVIER \(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: Tue, 16 Nov 2010 16:47:32 -0000

On 10 Nov 2010, at 22:08, Mikael Abrahamsson wrote:

> On Wed, 10 Nov 2010, Mike Hammer (hmmr) wrote:
> 
>> 3) The people that build and operate the networks will double (quadruple?) their investments for no additional return out of the goodness of their hearts.
> 
> No, they're going to do it because if they don't give the customers what they promised, their customers are going to leave. This is if there is a functional market and customers actually have a choice of providers. I realise this is not the case in parts of the world, but that doesn't mean we should solve that by technical means, that's a political and regulatory problem, it doesn't have any technical solution.
> 
> Let's not forget that if you're congesting your core and distribution, you're not delivering what your customers have purchased. Period.
> 

It depends what the customer has purchased. Many times what the customer *thinks* they have purchased and what they have *actually* purchased are not the same.

> Everything else is just smoke and mirrors.
> 
> Congestion is acceptable on the customer access, it's not acceptable in the core. That means that any flows/pakets that should yield, are within a single customer domain, and thus in the customers own interest.

I used to work at a large PTT. Our design was to make the core non-blocking (i.e. does not drop packets except under multiple failures) and constrain the backhaul[1] (and to a lesser extent the access line itself).

Your sentence above seems to ignore the backhaul? Which is strange as the backhaul is a significant proportion of the overall cost and larger than the cost of the core itself.

Ben

[1] The bit that transports & aggregates many access connections into the core.