Re: [httpstreaming] QoE feedback support

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Gunnar Heikkilä [mailto:[e-mail]]
> 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: [e-mail] [mailto:[e-mail]] 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" <[e-mail]> 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: [e-mail] [ <mailto:[e-mail]> mailto:httpstreaming-
> [e-mail]] 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.
> 
>