IETF Logo Mail Archive

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

"DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com> Fri, 12 November 2010 09:12 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 B5C7928C111; Fri, 12 Nov 2010 01:12:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.077
X-Spam-Level:
X-Spam-Status: No, score=-4.077 tagged_above=-999 required=5 tests=[AWL=-1.828, 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 lNcJChNwDzO1; Fri, 12 Nov 2010 01:12:13 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id A301A28C110; Fri, 12 Nov 2010 01:12:12 -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 oAC9CeUp010250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Nov 2010 10:12:40 +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 10:12:40 +0100
From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>, "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
Date: Fri, 12 Nov 2010 10:12:38 +0100
Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP
Thread-Index: AcuB4Vl8kL6F99JJR5asvgwyuxDp7wAZ+ARA
Message-ID: <3349FECF788C984BB34176D70A51782F1687808C@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: 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>, httpstreaming <httpstreaming@ietf.org>, "conex@ietf.org" <conex@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "Mike Hammer (hmmr)" <hmmr@cisco.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 09:12:20 -0000

 
You said:

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

Then, why on earth ALL ISPs are using QoS in THEIR networks to guarantee their own VoIP and Broadcast TV services to their customers???

QoS is ALWAYS a MUST for ISPs to ensure real-time services at any moment. Q-HTTP is trying to open up that window to other third parties.

And about "network state", there are different solutions to implement this, one includes network state, BUT IT IS NOT THE ONLY ONE. Indeed we tested one alternative in our lab with actual equipment....

    Saludos,
         Luismi

-----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

v2.23.0 | Report a Bug | By Email