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

"GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com> Thu, 11 November 2010 23:02 UTC

Return-Path: <jose_javier.garcia_aranda@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 291713A657C; Thu, 11 Nov 2010 15:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.655
X-Spam-Level:
X-Spam-Status: No, score=-3.655 tagged_above=-999 required=5 tests=[AWL=-1.406, 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 WaLW5Ps0CWOz; Thu, 11 Nov 2010 15:02:38 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 9F9CB3A635F; Thu, 11 Nov 2010 15:02:38 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oABN2NMq015406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Nov 2010 00:02:24 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 12 Nov 2010 00:02:23 +0100
From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Date: Fri, 12 Nov 2010 00:02:21 +0100
Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP
Thread-Index: AcuB4Vl8kL6F99JJR5asvgwyuxDp7wADcA+A
Message-ID: <3349FECF788C984BB34176D70A51782F16877F9C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.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> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <alpine.DEB.1.10.1011112134270.2639@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.1.10.1011112134270.2639@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: 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
Cc: "dispatch@ietf.org" <dispatch@ietf.org>, httpstreaming <httpstreaming@ietf.org>, "conex@ietf.org" <conex@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "Mike Hammer \(hmmr\)" <hmmr@cisco.com>, "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" <luismi.diaz@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: Thu, 11 Nov 2010 23:02:40 -0000

Mikael,

Since several years ago, ARPU is frozen and even it has been reduced a little. But traffic grows each year, and as you say, profit goes down. I have check ARPU from Spanish operators and they are reduced
Each year, a little, but the investments in network must increase to support the traffic growing.

An operator can do much more than micropayments and location. Can provide location, presence, availability status, geofencing functionalities, profiling, security based on attack patterns and virus signatures, child protection navigation, unified communications like integration voicemail to social networks, QoS (based on priorization, reservation, traffic mode at access nodes, traffic engineering, path computation) , storage, Content delivery network services, IPTV and IPTV based services, advertising, interactive advertising over IPTV, security, billing, wallet services for micropayments, remote call control, click to dial services, application store services, exposure of messaging services ( MMS, SMS), instant messaging services.....


Priorization reduce queue times, with network full or not. For example, IPTV services offered by operators uses priorization. But do not reduce QoS to priorization. There are more operations involved in QoS.


Regarding latency, it is possible reduce the latency using different operations over the network elements, such as changing traffic mode, choose a good path, priorization and so on. With around 50ms it is possible play a lot of virtualized games. Depending on the required latency, the application can work with a good user experience. But this is not only applicable to virtualized games, but also to traditional online gaming, in which latencies sometimes makes not possible to play against users located in other countries, and in that case constraints are not very restricted , however without QoS, they are impossible to achieve today. 

Hard-core gamers have a high willingness to pay for virtualized games, but today content providers can not offer virtualized games because there is not QoS on demand in Internet.

Have you read the draft? I promise you that Q-HTTP perhaps has an horrible name, but it is KISS, for sure. It is application level, and Q-HTTP alerts can be used for a lot of possibilities from  adapting mechanisms ( reduce bitrate or functionalities)  to priorization , reservation, or whatever. It is not said what to do with the alerts in the draft. It is only a powerful tool.


- Jose Javier


-----Mensaje original-----
De: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
Enviado el: jueves, 11 de noviembre de 2010 21:44
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Mike Hammer (hmmr); Ingemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: RE: [dispatch] [conex] [httpstreaming] Q-HTTP

On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:

> Service providers are worried about ARPU. It is decreasing becasue the 
> "exaflood" phenomenon. The exponential traffic can not be sustained by 
> the network, with incremental increases in bandwidth.

I don't get it. Are you saying that because there is more traffic, the user is paying less money per month? Yes, profit per customer might be down, but why should traffic volume decrease revenue?

> These ISP capabilities can be priced to developers/content providers, 
> increasing ISP revenues. Capabilities such as location, presence, billing, security, QoS....

I agree that an ISP can be a micropayment provider and also provice some location information.

> One of the most important is QoS. If developers can not find 
> profitable business Models, innovation is compromised. QoS means a mix 
> of traffic engineering + priorization + etc

Packet prioritization is only of value when the network is full. QoS is only of interest when BE works badly.

> Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) to 
> enable virtualization of games (like www.onlive.com, but using the 
> network instead locating servers at last mille)

I don't get this either. You can't play an FPS with tens of milliseconds of network delay, so you need to locate servers close to the customers to keep latency low, plus you also don't want the access latency to eat up your latency budget so ADSL and cable goes out the window anyway, the only thing left is the sub-millisecond latency of ETTH.

Btw, I think Q-HTTP is a horrible idea. It seems require a lot of state in the network. State is expensive. What happened to KISS principle?

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