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

"GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com> Thu, 11 November 2010 06:55 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 AED3D3A68B9; Wed, 10 Nov 2010 22:55:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.745
X-Spam-Level:
X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.504, 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 VUUDpFSdMJom; Wed, 10 Nov 2010 22:55:05 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E034A3A69C8; Wed, 10 Nov 2010 22:54:44 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAB6t3BH029506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Nov 2010 07:55:03 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 11 Nov 2010 07:55:03 +0100
From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>, httpstreaming <httpstreaming@ietf.org>, "conex@ietf.org" <conex@ietf.org>
Date: Thu, 11 Nov 2010 07:55:01 +0100
Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP
Thread-Index: AcuBI9H89oeASx/0Tda40uG+tV0XGgAR2aVA
Message-ID: <3349FECF788C984BB34176D70A51782F16877A37@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>
In-Reply-To: <alpine.DEB.1.10.1011102303170.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.80
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: Mikael, "pkyzivat@cisco.com" <pkyzivat@cisco.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "Mike Hammer \(hmmr\)" <hmmr@cisco.com>
Subject: Re: [httpstreaming] [conex] [dispatch] 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 06:55:09 -0000

I fully agree with Paul Kyzivat and Luis miguel, in summary:

- the contractual obligations of operators are very "light" "up to NNN bps".
- these "light" obligations allow a low flat fee but not allow quality services
- "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

As Luis Miguel said, we need the tools (Q-HTTP can be) to:

- Provide the flow requirements. Not all the services require the same parameters from the network
- A way to measure those parameters e2e.
- A way to "cry for help" if those parameters are below (or critically close) the limits
- A way to account for this. Content provider ask for QoS, and would pay for that. 


Other scenarios in which the final user pays for QoS are possible, but in general terms, i believe that Content provider is who is going to pay for that, not final user, which pays the "flat fee" for a best-effort internet access



-Jose Javier