Re: [httpstreaming] QoE feedback support

Mark Watson <watsonm@netflix.com> Thu, 11 November 2010 00:56 UTC

Return-Path: <watsonm@netflix.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 95F603A688D for <httpstreaming@core3.amsl.com>; Wed, 10 Nov 2010 16:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 pJ4-nRcsFjWR for <httpstreaming@core3.amsl.com>; Wed, 10 Nov 2010 16:56:35 -0800 (PST)
Received: from mx2.netflix.com (mx2.netflix.com [208.75.77.145]) by core3.amsl.com (Postfix) with ESMTP id D7A9D3A6872 for <httpstreaming@ietf.org>; Wed, 10 Nov 2010 16:56:33 -0800 (PST)
Received: from exchnmc101.netflix.com (exchnmc101.netflix.com [10.64.32.131]) by mx2.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id oAB0uwN8025633; Wed, 10 Nov 2010 16:56:58 -0800
Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by exchnmc101.netflix.com ([fe80::4894:38ba:ac0c:e4bc%13]) with mapi; Wed, 10 Nov 2010 16:56:57 -0800
From: Mark Watson <watsonm@netflix.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Date: Wed, 10 Nov 2010 16:56:31 -0800
Thread-Topic: [httpstreaming] QoE feedback support
Thread-Index: AcuBO1Z3X82Whg1OTmKt6j/yAbWD1Q==
Message-ID: <88D9E111-B926-4916-9E09-64B43FF0D639@netflix.com>
References: <04CAD96D4C5A3D48B1919248A8FE0D540DA6707F@xmb-sjc-215.amer.cisco.com> <B8EF0FF5-6753-4841-9E79-F407C5CD1A40@apple.com> <B4DD6B85-F204-42DB-B442-A16EF2124B2D@cisco.com> <BCAD297FC0C0D244894589EE45FE8B470FF21A9D8B@ESESSCMS0364.eemea.ericsson.se> <04CAD96D4C5A3D48B1919248A8FE0D540DA670CF@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DA670CF@xmb-sjc-215.amer.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, httpstreaming <httpstreaming@ietf.org>, David
Subject: Re: [httpstreaming] QoE feedback support
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 00:56:37 -0000

Ali,

There was push-back on the QoE name in MPEG too an the work item is now called 'Quality Metrics'.

As Dave say there are (at least) two kinds if measurement (i) those that relate only to what the user actually experienced (start-up time, playback stalls which version of the audio/video was actually played, when switches occured) and (ii) metrics to do with the how that experience was actually delivered: bandwidth measurements, buffer sizes, server response times etc.

...Mark 

Sent from my iPhone

On Nov 10, 2010, at 7:33 AM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

> 
>> -----Original Message-----
>> From: Gunnar Heikkilä [mailto:gunnar.heikkila@ericsson.com]
>> Sent: Wednesday, November 10, 2010 11:26 PM
>> To: Ali C. Begen (abegen); David Singer
>> Cc: Ingemar Johansson S; httpstreaming; Gunnar Heikkilä
>> Subject: RE: [httpstreaming] QoE feedback support
>> 
>> The acronym QoE is maybe not the best choice of name, but the concept allows the 3GPP operator to get a better
> 
> It is not the best choice and actually it is pretty misleading.
> 
>> understanding on how the streaming service works for the end client. Some more integrated services (like circuit-switched
>> AMR voice) can typically be handled by measuring things within the 3GPP network itself (for instance codec mode
>> adaptation, frame loss etc.), but other services (like HTTP streaming) have a lot more freedom for the end client to decide
>> how to play out the media.
> 
> Indeed. That's why we should not call it QoE.
> 
>> This is a good thing, as clients can choose different strategies to satisfy the end user, but it also means that it is difficult for
>> the operator to understand if his network works good enough for these type of services. The metrics reported back from the
>> client are typically things which are not possible to measure in the network, but which does affect the media "enjoyment" a
>> lot. For instance, the length of the initial buffering, or any re-buffering occurances etc.
>> 
>> Not rocket science, not perfect, but still information which help the operator to see a more complete picture of his network
>> and the services used...
> 
> I am all for reporting useful stuff from the clients in an extensible and modular way.
> 
> -acbegen
> 
>> /Gunnar
>> 
>> ________________________________
>> 
>> From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen)
>> Sent: on 10 november 2010 15:57
>> To: David Singer
>> Cc: Ingemar Johansson S; httpstreaming
>> Subject: Re: [httpstreaming] QoE feedback support
>> 
>> 
>> Sure but this does not answer my question afaict.
>> 
>> 
>> -acbegen
>> 
>> On Nov 10, 2010, at 9:09 PM, "David Singer" <singer@apple.com> wrote:
>> 
>> 
>> 
>> 
>>    On Nov 10, 2010, at 13:52 , Ali C. Begen (abegen) wrote:
>> 
>>    > I really find it very unattractive to call this stuff QoE reporting/feedback. Give me one example on what metric
>> would measure my level of pleasure from a streaming service ;)
>>    >
>>    > -acbegen
>>    >
>>    >> -----Original Message-----
>>    >> From: httpstreaming-bounces@ietf.org [ <mailto:httpstreaming-bounces@ietf.org> mailto:httpstreaming-
>> bounces@ietf.org] On Behalf Of Ingemar Johansson S
>>    >> Sent: Wednesday, November 10, 2010 8:42 PM
>>    >> To: httpstreaming
>>    >> Subject: [httpstreaming] QoE feedback support
>>    >>
>>    >> FYI
>>    >>
>>    >> This document describes how QoE support is proposed for HTTP streaming in 3GPP.
>>    >> <http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/Ad-hoc_MBS/Docs_AHI/S4-AHI118.zip>
>> http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/Ad-hoc_MBS/Docs_AHI/S4-AHI118.zip
>>    >> I suspect that there exist a newer version and/or a better description.
>>    >>
>> 
>>    we were actually just discussing this area at a 3G meeting, and I realized that there are really two kinds of metrics it
>> is useful to get from clients:
>> 
>>    a) truly Qo Experience, that is, experiential metrics -- the mismatch between the user's expectation, and reality (tune-
>> in delay, media they wanted to see but did not, and so on)
>>    b) operational metrics -- amount of data fetched, buffer sizes maintained, and so on
>> 
>>    There are some in the middle, like bandwidth experienced, which are both operational and affect experience.
>> 
>>    David Singer
>>    Multimedia and Software Standards, Apple Inc.
>> 
>> 
> 
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
>