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

"DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com> Thu, 11 November 2010 10:28 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 9AA3E3A6929; Thu, 11 Nov 2010 02:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.197
X-Spam-Level:
X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 HtYWPoV4Rcip; Thu, 11 Nov 2010 02:28:38 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 6A1F73A683A; Thu, 11 Nov 2010 02:28:38 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oABASu6P027123 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Nov 2010 11:29:03 +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; Thu, 11 Nov 2010 11:29:00 +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: Thu, 11 Nov 2010 11:28:58 +0100
Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP
Thread-Index: AcuBhhNkF+3U5kbFSBCAYGgNZwUMjAABD0cQ
Message-ID: <3349FECF788C984BB34176D70A51782F16877BB6@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
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> <3349FECF788C984BB34176D70A51782F16877A37@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <alpine.DEB.1.10.1011110857470.2639@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.1.10.1011110857470.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.80
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>
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 10:28:39 -0000

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 9:01
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; Kathy McEwen
Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP

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

> I fully agree with Paul Kyzivat and Luis miguel, in summary:
>
> - the contractual obligations of operators are very "light" "up to NNN bps".

In my market the consumer rights entity has worked with ISPs and gotten rid of that. It's not "between X and Y megabit/s as per this test-tool". 
If the ISP doesn't provide this, the customer has the right to cancel the contract.

[[Luismi]]: You are very lucky :). This is not the standard in most part of the world.

> - these "light" obligations allow a low flat fee but not allow quality 
> services

We have lower flat fees that in most markets, this is due to actual competition in the market. We also generally don't have any congestion in the ISP network, only on access.

[[Luismi]]: Congestion on access is also a big problem. Q-HTTP provides end-to-end checking of compliance of SLA, and if network is violating that (no matter where) Q-HTTP will inform "someone" of the violation. After that, several options are possible (for instance, ACP can recode video to a lower bit-rate in order to fit in) and that specific flow can get higher priority (only on access or in the whole network) to avoid congestion. We are not taking about HOW we can do that, first of all we need the tools to detect WHEN we need to do the magic....

> - "new age services" needs QoS, and final user will pay for that 
> service to the content provider
> - content provider will pay network operator to provide the service to 
> the end user with a minimum quality of experience
> - Tier-1 providers will need to evolve their model from a "per-bit" 
> schema to a "per-bit-per-QoS" one

I strongly disagree. The Internet was successful because of "bill and keep". Let's not kill what has been a huge success.

[[Luismi]]: We are not killing, we are evolving. Bill and keep was nice when network usage was fair, since the only services available where much alike. Today, comparing emailing or web surfing with video on demand or online gaming (and beyond, with virtualized services) is not fair anymore, so we need to evolve Internet to a non-fair world.

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