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

"DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com> Wed, 17 November 2010 10:08 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 B92263A68A8; Wed, 17 Nov 2010 02:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.928
X-Spam-Level:
X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 WpzHeDExHlpv; Wed, 17 Nov 2010 02:08:35 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id EAD1B3A68BE; Wed, 17 Nov 2010 02:08:34 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAHA7NsM032574 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2010 11:09:07 +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; Wed, 17 Nov 2010 11:08:31 +0100
From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com>
To: Marshall Eubanks <tme@americafree.tv>
Date: Wed, 17 Nov 2010 11:08:29 +0100
Thread-Topic: [dispatch] [httpstreaming] [conex] Q-HTTP
Thread-Index: AcuFrpoz+nDGpWHISxWNLFSoo9eM0QAj/qgw
Message-ID: <3349FECF788C984BB34176D70A51782F16BB3AAA@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> <3349FECF788C984BB34176D70A51782F1687808C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7C3A8DA4-18F3-4AA4-A2F4-325FC2D817DA@americafree.tv>
In-Reply-To: <7C3A8DA4-18F3-4AA4-A2F4-325FC2D817DA@americafree.tv>
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.80
X-Mailman-Approved-At: Wed, 17 Nov 2010 17:05:38 -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>, Mikael, "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: Wed, 17 Nov 2010 10:08:36 -0000

I have worked extensively (in engineering and network design) for every ISP on Spain (Telefonica, France Telecom, Orange, BT...) and all of them have QoS in their network. They use it to provide VoIP, Broadcast TV and to protect Bussiness Services (VPLS and IP-VPN). Indeed the only traffic that is Best-Effort is internet traffic for residential users (internet for corporate customers has also higher priority).

Maybe they are not SELLING QoS directly to their customers. But for sure they are USING it a lot. What we propose is opening that feature to everyone, providing a tool to monitor and control QoS to everyone.


    Saludos,
         Luismi

-----Mensaje original-----
De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre de Marshall Eubanks
Enviado el: martes, 16 de noviembre de 2010 17:51
Para: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Mikael Abrahamsson
Asunto: Re: [dispatch] [httpstreaming] [conex] Q-HTTP


On Nov 12, 2010, at 4:12 AM, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

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

I have three personal / office ISP accounts for Internet access. If any are offering QOS as a service, they sure haven't told me. (One, the cable company, does do a "walled garden" type solution for IPTV, but I don't think that that is the type of QOS you are talking about.)  

Regards
Marshall


> 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
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch