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

"DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com> Fri, 12 November 2010 08:54 UTC

Return-Path: <luismi.diaz@alcatel-lucent.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 70AF63A6B09; Fri, 12 Nov 2010 00:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.381
X-Spam-Level:
X-Spam-Status: No, score=-4.381 tagged_above=-999 required=5 tests=[AWL=-2.132, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 bwJonjvdcS8M; Fri, 12 Nov 2010 00:54:00 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id E3F8F3A6B0D; Fri, 12 Nov 2010 00:53:54 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAC8sM6E007397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Nov 2010 09:54:23 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 12 Nov 2010 09:54:22 +0100
From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Date: Fri, 12 Nov 2010 09:54:20 +0100
Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP
Thread-Index: AcuB0uhyyyCMZmR/ToGi1o00hUYJ2QAcgFuA
Message-ID: <3349FECF788C984BB34176D70A51782F16878047@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <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> <C4064AF1C9EC1F40868C033DB94958C7031F1154@XMB-RCD-111.cisco.com> <alpine.DEB.1.10.1011111806430.2639@uplift.swm.pp.se> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <alpine.DEB.1.10.1011111957580.2639@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.1.10.1011111957580.2639@uplift.swm.pp.se>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: es-ES, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Ingemar, httpstreaming <httpstreaming@ietf.org>, "conex@ietf.org" <conex@ietf.org>, Johansson S <ingemar.s.johansson@ericsson.com>, "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
Subject: Re: [httpstreaming] [dispatch] [conex] 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: Fri, 12 Nov 2010 08:54:07 -0000

Few comments in-line.... 


    Saludos,
         Luismi

-----Mensaje original-----
De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre de Mikael Abrahamsson
Enviado el: jueves, 11 de noviembre de 2010 20:02
Para: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; Kathy McEwen; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP

On Thu, 11 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

>   Just a different approach. Think in a traffic jam. I know it would 
> be nice to live in a wonderful world with no jams, but they happen. 
> Know compare you, going back home from work, and an ambulance with 
> someone dying inside. Everybody gets away to let ambulance drive 
> first. And that's OK.

When there is a traffic jam due to an accident it's ok. Where there is LA style traffic jams 12 hours of the day, that's not ok.

[[Luismi]]: I dont look why it is happening. It is just happening. And we need to do something about it in both cases (accident and 12-hour daily jam). 

>   Now think on Internet. You are playing a Real-Time game and your 
> neighbours are just downloading files. They can afford some amount of 
> traffic loss (+delay/jitter) since TCP retransmisions will do the 
> trick (just will take a little longer to get the job done) while you 
> cannot afford losing (+delaying/jitterin) your traffic because if it 
> happens, your opponent will blow you away from the arena. That's the 
> point, all traffic flows are NOT the same and need different SLAs.

It would help the customer to get different treatment of his/her flows on the access. It would help the ISP and not the customer to do the same in the distribution/core. Who do we want to help? Is it the end user or is it the ISP? In the discussions in CONEX I mostly see people wanting to help the ISP, not the end user.

[[Luismi]]: There is one only real thing we can trust in: ISP is there because of PROFIT. If there is no profit there will be no investment at all and everything will just stale, that is precisely the reason while new real-time services are not flying on Internet as it should. We are helping ISPs to do MORE with the same money, and that will benefit users. With Q-HTTP we are also providing the tools to users to "audit" what they are paying for. Users will pay extra money for superb services (we are doing that right now when you pay a World of Warcraft or OnLive subscription) and part of that money will end-up on the ISP. Sharing profit between all the players is definetively a good thing IMHO.

> - Enables network operators to generate more revenue for 
> "over-requirements". I dont think real-time was in mind whe Internet 
> was created and we need to provide ISPs with new tools like this.

"over-requirement" as in "I want to actually get what you promised to deliver to me"?

[[Luismi]]: The problem is that ISPs promises are just vague. Up to X Mbps, with no delay/jitter guarantees is just fine for a lot of applications. It is just not enough for real-time. Besides, a few seconds congestion (for instance, a fiber goes down and all traffic re-routes by another path that becomes 1.5 to 1 congested) will produce a slow down in "standard" service and a complete melt-down in real-time. THAT's what we want to protect. Real-Time application will obtain higher priority during congestion (thus slowing down even more the standard services) and EVERYTHING will be saved. Standard services will survive with a period of "half-speed" and Real-Time will survive unaffected.

I don't buy it.

[[Luismi]]: Then there are a lot of services that never will fly out on Internet. Take a look on OnLive service. They provide virtualized gaming (play XBOX games on your TV without the console, just with a small set-top-box that receives video and sends keys pressed on the pad) by just bypassing the network and installing PoPs just half mile away from your home. That is not economically optimized as you can imagine thus they are translating that into a very expensive service. Just because network does not provide what they need. With QoS, they can offer a centralized service, with really cheaper deployment, lower the service fee to users (win), making more profit (win) and paying a % of that to ISP (win). If we like win-win, you must love this win-win-win (and even better, ISP will re-invest part of that profit on network).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch