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

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 11 November 2010 15:31 UTC

Return-Path: <swmike@swm.pp.se>
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 D9AA23A6970; Thu, 11 Nov 2010 07:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
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 6mWIsQvD9oXN; Thu, 11 Nov 2010 07:31:40 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id C549B3A683F; Thu, 11 Nov 2010 07:31:39 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9EB599C; Thu, 11 Nov 2010 16:32:08 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9C4419A; Thu, 11 Nov 2010 16:32:08 +0100 (CET)
Date: Thu, 11 Nov 2010 16:32:08 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Mike Hammer (hmmr)" <hmmr@cisco.com>
In-Reply-To: <C4064AF1C9EC1F40868C033DB94958C7031F10D0@XMB-RCD-111.cisco.com>
Message-ID: <alpine.DEB.1.10.1011111616310.2639@uplift.swm.pp.se>
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> <C4064AF1C9EC1F40868C033DB94958C7031F10D0@XMB-RCD-111.cisco.com>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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, 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: Thu, 11 Nov 2010 15:31:43 -0000

On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote:

> So, you are assuming that the alternative provider is not subject to the 
> same economic constraints as the provider you are jumping from?  If that 
> were such an easy thing to do, you would see many more players on the 
> field, and fewer commentators in the stands.

In my market there are lots of players and they all have possibility to 
reach end users because there are "neutral" L1 providers to rent 
fiber/copper from. Competition works, and it stops aggregation congestion.

> Agree, that the core should not be getting congested, but this problem 
> gets worse progressively as you approach the customer edge.  And the 
> costs to overprovision the edge go up correspondingly.  The last mile is 
> the most expensive.

The customer unique connection is ok to congest, it's running at the speed 
the customer is paying for. It's everything up from that that should 
"never" be congested, because then you're not giving the customer what 
they're paying for. It's a breach of contract, pure and simple. You're 
free to statistically overbook your aggregation up to the point where it's 
extremely rarely congesting.

Would you accept a telephony network that gave you no dialtone half of the 
time you tried? I don't get it. Why would ISPs get away with not 
delivering what they have sold and why should we help them do this?

What the IETF and everybody should focus on is SHOWING to the end users 
that there is congestion occuring, so they have a tool to give their 
consumer protection agency this informaiton to demand to cancel their 
contract because their ISP is not delivering on its promise.

This works in all other markets, there false advertising is not tolerated, 
why should it be in the ISP market? If you're buying 100 megabit/s of 
residential bw you should be able to use this speed at least 99% of the 
time, otherwise your ISP is overselling the resource and you're not 
getting what you have bought. If the ISP has gigabit aggregation it's most 
likely that they can get away with 1000 users or more on this gige at this 
speed, but they will not get away with it by doing 200 meg aggregation.

People talk about "fair". Fair business practice is to deliver what you've 
sold. Fair is to treat every customers traffic equally, to deliver the 
packets they want delivered. That is the job of the ISP. It's not to 
mistreat some traffic or discriminate. If anything, THAT is the unfair 
part.

>
> -----Original Message-----
> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
> Sent: Wednesday, November 10, 2010 5:08 PM
> To: Mike Hammer (hmmr)
> Cc: David Singer; dispatch@ietf.org; Kathy McEwen; httpstreaming;
> conex@ietf.org; Ingemar Johansson S; Mark Watson; GARCIA ARANDA,
> JOSEJAVIER (JOSE JAVIER)
> Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP
>
> 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.
>
> 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.
>
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
>

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se