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
- Re: [httpstreaming] [dispatch] Q-HTTP Qin Wu
- Re: [httpstreaming] [dispatch] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] Q-HTTP Mark Nottingham
- Re: [httpstreaming] [dispatch] Q-HTTP Ingemar Johansson S
- Re: [httpstreaming] [dispatch] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] Q-HTTP David Singer
- Re: [httpstreaming] [dispatch] Q-HTTP Gunnar Heikkilä
- Re: [httpstreaming] [dispatch] Q-HTTP David Singer
- Re: [httpstreaming] [dispatch] Q-HTTP Gunnar Heikkilä
- Re: [httpstreaming] [dispatch] Q-HTTP Ingemar Johansson S
- Re: [httpstreaming] [dispatch] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] Q-HTTP Ali C. Begen (abegen)
- Re: [httpstreaming] [dispatch] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] Q-HTTP Henry Sinnreich
- Re: [httpstreaming] [dispatch] Q-HTTP Lars Eggert
- Re: [httpstreaming] [dispatch] Q-HTTP Kathy McEwen
- Re: [httpstreaming] [dispatch] Q-HTTP Mark Watson
- Re: [httpstreaming] [dispatch] Q-HTTP Ben Niven-Jenkins
- Re: [httpstreaming] [dispatch] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] Q-HTTP Ingemar Johansson S
- Re: [httpstreaming] [dispatch] Q-HTTP Dirk Kutscher
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP David Singer
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Van Caenegem, Tom (Tom)
- Re: [httpstreaming] [dispatch] Q-HTTP David Singer
- Re: [httpstreaming] [dispatch] Q-HTTP David Singer
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mcdysan, David E
- Re: [httpstreaming] [dispatch] Q-HTTP Kathy McEwen
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP David Singer
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Kathy McEwen
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [dispatch] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP ken carlberg
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Roland Bless
- Re: [httpstreaming] [dispatch] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [dispatch] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [dispatch] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [dispatch] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Toby Moncaster
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Toby Moncaster
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Hadriel Kaplan
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Henry Sinnreich
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Janet P Gunn
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Kevin Mason
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [dispatch] Q-HTTP Marshall Eubanks
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Ben Niven-Jenkins
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Marshall Eubanks
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Ben Niven-Jenkins
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP David Singer
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP David Singer
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Benjamin Niven-Jenkins
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [dispatch] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Benjamin Niven-Jenkins
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mikael Abrahamsson
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Marshall Eubanks
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Mark Baugher
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Mike Hammer (hmmr)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP Adam Roach
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [dispatch] [conex] Q-HTTP DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Woundy, Richard
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Kathy McEwen
- Re: [httpstreaming] [conex] [dispatch] Q-HTTP Marshall Eubanks