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

"Mike Hammer (hmmr)" <hmmr@cisco.com> Thu, 11 November 2010 16:14 UTC

Return-Path: <hmmr@cisco.com>
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 572453A697E; Thu, 11 Nov 2010 08:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.556
X-Spam-Level:
X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 J+WUXr833MAe; Thu, 11 Nov 2010 08:14:19 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B6D7D3A6822; Thu, 11 Nov 2010 08:14:17 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFOl20ytJXG//2dsb2JhbACiRXGlbptUhUoEhFpViDo
X-IronPort-AV: E=Sophos;i="4.59,183,1288569600"; d="scan'208";a="181076440"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2010 16:14:44 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id oABGEhsx021255; Thu, 11 Nov 2010 16:14:43 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 10:14:43 -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: Thu, 11 Nov 2010 10:14:42 -0600
Message-ID: <C4064AF1C9EC1F40868C033DB94958C7031F1154@XMB-RCD-111.cisco.com>
In-Reply-To: <alpine.DEB.1.10.1011111616310.2639@uplift.swm.pp.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP
Thread-Index: AcuBtZ1WcFN+xDTETyq3gnYdU5nviQAAkfoQ
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> <alpine.DEB.1.10.1011111616310.2639@uplift.swm.pp.se>
From: "Mike Hammer (hmmr)" <hmmr@cisco.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-OriginalArrivalTime: 11 Nov 2010 16:14:43.0938 (UTC) FILETIME=[8D483C20:01CB81BB]
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 16:14:20 -0000

Mikael,

I think the crux of our disagreement here is the difference between what
it takes to be an ISP and what it takes to be an access provider.  The
economics are different.  Apples and oranges.  Saying it works for
oranges means it makes sense for apples is a non-sequitor.

<Start political view>
It is nice that you have a regulated monopoly of L1 in your market, but
that is not the case everywhere.  Who you are now is what you were when.
Some investors that paid to put copper or fiber into the ground would
prefer that the fruits of their labor not be stolen from them by
government fiat. 
<End of political view>

The telephone network had 100 years to get the blocking rates and
traffic engineering right.  Even now, in some countries you do still get
busy signal.  Should you then have the right to go out an cancel your
contract as a result?  I'll leave that to the market to decide.  And
yes, I support not having too lengthy a contract.  After all, we need to
vote with our feet every so often.

However, comparing blocking (dial-tone means nothing, busy signal does)
of QoS guaranteed telephone links with non-QoS based congestion is
self-contradictory.  You are in essence saying that on the one hand
providers should not have the tools to provide QoS guarantees and on the
other hand slapping them for not being able to provide a QoS guarantee.
Now how fair is that?

Also, comparing low-volume fairly predictable traffic flows like voice
to bursty flows like video is also problematic.

I would not be so quick to deride the advertizing as false as not very
clear, but I do think there could be better education of the public.  
(Have you never tried to explain this to a non-techie and watched their
eyes glaze over?)

As for treating traffic equally, you apparently don't care much about
real-time interactive applications.  That is your choice.  But, please
don't impose that on everyone.

Mike


-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
Sent: Thursday, November 11, 2010 10:32 AM
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 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