Re: [httpstreaming] [dispatch] Q-HTTP

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 09 November 2010 03:35 UTC

Return-Path: <ingemar.s.johansson@ericsson.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 7C3D73A68EB; Mon, 8 Nov 2010 19:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, 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 4p7TqkNt-pV7; Mon, 8 Nov 2010 19:34:59 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E26C128C1B8; Mon, 8 Nov 2010 19:34:57 -0800 (PST)
X-AuditID: c1b4fb39-b7b54ae000003464-fd-4cd8c178c415
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 25.7F.13412.871C8DC4; Tue, 9 Nov 2010 04:35:20 +0100 (CET)
Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 9 Nov 2010 04:35:20 +0100
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>, Qin Wu <sunseawq@huawei.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Date: Tue, 9 Nov 2010 04:35:03 +0100
Thread-Topic: [httpstreaming] [dispatch] Q-HTTP
Thread-Index: Act/YysCX7CwpgwoTOi2u5WUtY8rLwAWmcIA
Message-ID: <DBB1DC060375D147AC43F310AD987DCC180E504600@ESESSCMS0366.eemea.ericsson.se>
References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
In-Reply-To: <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: httpstreaming <httpstreaming@ietf.org>, "conex@ietf.org" <conex@ietf.org>
Subject: Re: [httpstreaming] [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: Tue, 09 Nov 2010 03:35:00 -0000

Hi

I have skimmed through the pdf, thanks for posting this. My immediate reaction is that this machanism is trying to react to indicators of congestion in various ways. 

An alternative would actually be ConEx (http://tools.ietf.org/wg/conex/charters). With ConEx enabled flows the re-feedback information can be used by both operator and user to verify that a SLA is met.
For instance, if a user is promised a bandwith of 200kbps for his gaming experience and still experience a high congetsion volume, this would be clearly visible for the operator (as well as the user). I don't believe that ConEx has outlined this particular use case but I would say that it should be doable.
ConEx has the benefit that it does not add much extra overhead, there are of course issues with ConEx (as with any other new technology)

Regads
/Ingemar

 

  

> -----Original Message-----
> From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) 
> [mailto:jose_javier.garcia_aranda@alcatel-lucent.com] 
> Sent: den 9 november 2010 00:33
> To: Qin Wu; dispatch@ietf.org
> Cc: httpstreaming
> Subject: Re: [httpstreaming] [dispatch] Q-HTTP
> 
> Hi Qin and all,
> 
> Now the Q-HTTP draft is accesible at 
> 
> http://www.ietf.org/id/draft-aranda-dispatch-qhttp-00.txt
> 
> In addition, i have attached in this email a FAQ document for 
> easier understanding of the protocol. This document clarifies 
> the philosophy and shows different alternatives for the implementation
> 
> Regards and thanks
> 
> - Jose javier
> 
> 
> -----Mensaje original-----
> De: Qin Wu [mailto:sunseawq@huawei.com] Enviado el: lunes, 08 
> de noviembre de 2010 15:35
> Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); dispatch@ietf.org
> CC: httpstreaming
> Asunto: Re: [dispatch] Q-HTTP
> 
> Hi, Joes Javier:
> Your bring a quite interesting draft. We have a Bar BOF on 
> HTTP streaming on Wednesday evening, Emenrald room, which 
> aims at  building new area and working out appropriate 
> working scope to offer more efficient transport and better 
> QoE. One of key issues we are ready to address is QOE 
> improvement. If you are interested, please join our discussion.
> Also you can track the following link for our meeting agenda, 
> location and time:
> http://www.ietf.org/mail-archive/web/httpstreaming/current/mai
> llist.html
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" 
> <jose_javier.garcia_aranda@alcatel-lucent.com>
> To: <dispatch@ietf.org>
> Sent: Monday, November 08, 2010 4:14 PM
> Subject: [dispatch] Q-HTTP
> 
> 
> 
> Hi experts, 
> 
> We are a group of researchers which have written a draft 
> about QoS measurements & reactions. We believe the 
> standardization of this topic could benefit internet 
> community in the coming years, for example for virtualization 
> of videogames through intenet. We would like to receive 
> comments and some feedback and also oppinions about the 
> target area, because we believe that the draft fits into 
> Real-time App and infrastructure Area scope, but currently 
> the draft is in "looking for an area" state
> 
>    The draft describes Q-HTTP (Quality HTTP) , which is an 
> application level protocol based on HTTP and SDP associated 
> to a new specific uri "httpq://..." intended for carrying out 
> quality negotiation and quality measurement between two 
> parties. The final goal of this process is to verify that a 
> certain application which depends on bandwidth, latency, 
> jitter parameters, will work under current network 
> conditions. Our idea tackles the fact that real-time services 
> (virtualization, on line gaming, video, voice) nowadays are 
> increasing and that in an internet (or WAN) environment 
> propagation conditions may change with time for our 
> connection; what works for most applications may not work for 
> real-time ones and they should have a standard way of 
> negotiating and verifying their requirements. Q-HTTP also 
> provides a mechanism of account/alerting when required 
> constraints are not met after the measurement is carried out.
>   
>  Implementation details on the actions to be triggered upon 
> reception/detection of QoS alerts exchanged by the protocol 
> are out of scope of this draft, it is application dependant 
> (e.g. increase quality, reduce bit-rate) or even network 
> dependant (e.g. change connection's quality profile).
> 
> Comments? Thanks
> 
> - Jose Javier
> 
> 
> 
> --------------------------------------------------------------
> ------------------
> 
> 
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
>