Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-01.txt

From: Roy Peterkofsky <[email-masked]>
Date: Wed, 01 Aug 2012 09:13:19 -0700

On 7/31/2012 10:33 PM, Y. Richard Yang wrote:
>
> - There are use cases to log client QoE, for example, freezing ratio 
> and # of freezing times. Such metrics may be only observable by the 
> End User Agent only. A dCDN may collect such data (from End User 
> Agent) and report to uCDN/CSP.

It is a good point that this metrics are of interest.  It seems 
unlikely, however, that a dCDN would have control over the end user 
agent.  That would more typically be under the control of the CSP. 
Therefore, I am not sure what value including this in the log format for 
communication between dCDNs and uCDNs would bring.

>
> Thanks.
>
> Richard
>
>
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12
>

-- 
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success 
<http://www.slideshare.net/skytide/the-4-keys-to-telco-cdn-success>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 01 Aug 2012 10:12:19 -0700

Hi Roy,

On 8/1/12 9:13 AM, Roy Peterkofsky wrote:
> It is a good point that this metrics are of interest. 

Glad you also agree that this is a type of metrics that ay have interest.
> It seems unlikely, however, that a dCDN would have control over the 
> end user agent.  That would more typically be under the control of the 
> CSP. 
It really depends on where the event handler(s) at the UA reports to. 
Some CSPs may use a third party analytics service, but it can be natural 
that a CDN provides this report as a part of the service. If it is the 
CDN who gets the reports and given that the uCDN delegates to the dCDN 
(say due to limited capacity/footprint), it is less likely that the uCDN 
is the reported target, but instead the uCDN. What do you think?

Richard

> Therefore, I am not sure what value including this in the log format 
> for communication between dCDNs and uCDNs would bring.
>
>
>>
>> Thanks.
>>
>> Richard
>>
>>
>>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 1 Aug 2012 19:38:33 +0000

On 1 Aug 2012, at 10:12, Y. Richard Yang wrote:

Hi Roy,

- There are use cases to log client QoE, for example, freezing ratio and # of freezing times. Such metrics may be only observable by the End User Agent only. A dCDN may collect such data (from End User Agent) and report to uCDN/CSP.

Glad you also agree that this is a type of metrics that ay have interest.
It seems unlikely, however, that a dCDN would have control over the end user agent.  That would more typically be under the control of the CSP.
It really depends on where the event handler(s) at the UA reports to. Some CSPs may use a third party analytics service, but it can be natural that a CDN provides this report as a part of the service.

While it is conceivable that CDNs could take on the role of collecting/aggregating user agent QoE stats on behalf a CSP, I think this is more of a value add service than a core delivery service.
Considering that:
* our charter guides us towards delivering first a base set of capabilities in a fairly short timeframe
* the target date for delivering the CDNI Logging interface is _December 2012_
* supporting collection of user agent QoE Stats would involve a number of interesting issues (e.g. what protocol does CDN uses to obtain the stats from the enduser? how can the dCDN be authorized by CSP to collect stats from CSP-controlled user agent considering the CSP may not have any relationship with the dCDN and in fact may not even be ware of it?),
I recommend that we keep collection of user agent QoE stats on our list of candidates for rechartering.

But along the lines of improving the performance tracking through a CDNI environment, a more modest but achievable goal may be for the CDNI Logs to include a few more perf related fields that can be directly measured by the Surrogate. I believe the DASH performance specs include several reference points for measurement on the client side and the lowest level reference point relates to transport/delivery: perhaps we could look at those and see if we could extract a few meaningful perf metrics for which we could define the mirror server-side metric. And allow inclusion of those in our CDNI logs.

Makes sense ?

Thanks

Francois

If it is the CDN who gets the reports and given that the uCDN delegates to the dCDN (say due to limited capacity/footprint), it is less likely that the uCDN is the reported target, but instead the uCDN. What do you think?

Richard

Therefore, I am not sure what value including this in the log format for communication between dCDNs and uCDNs would bring.

Thanks.

Richard

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com/>
Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12

--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com<http://www.skytide.com/>
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success<http://www.slideshare.net/skytide/the-4-keys-to-telco-cdn-success>

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 2 Aug 2012 06:10:14 +0800

Hi Francois,

I was thinking the typical http based UA (say in JavaScript) report. The
setting is that the http report url will point to the uCDN who then direct
to the dCDN. In the case of uCDN with limited cap, this reporting is
delegated to dCDN as well. But of course QoE collection may not be a core
service, and may even have a problem of conflict of interest. Looking more
into the problem during rechartering makes sense to me. The idea of more
server side metrics is interesting. I will look it up to share comments, if
any.

Thanks!

Richard

On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote:

> - There are use cases to log client QoE, for example, freezing ratio and #
> of freezing times. Such metrics may be only observable by the End User
> Agent only. A dCDN may collect such data (from End User Agent) and report
> to uCDN/CSP.
>
>
> It seems unlikely, however, that a dCDN would have control over the end
> user agent.  That would more typically be under the control of the CSP.
>
> It really depends on where the event handler(s) at the UA reports to. Some
> CSPs may use a third party analytics service, but it can be natural that a
> CDN provides this report as a part of the service.
>
>
>  While it is conceivable that CDNs could take on the role of
> collecting/aggregating user agent QoE stats on behalf a CSP, I think this
> is more of a value add service than a core delivery service.
> Considering that:
> * supporting collection of user agent QoE Stats would involve a number of
> interesting issues (e.g. what protocol does CDN uses to obtain the stats
> from the enduser? how can the dCDN be authorized by CSP to collect stats
> from CSP-controlled user agent considering the CSP may not have any
> relationship with the dCDN and in fact may not even be ware of it?),
>  But along the lines of improving the performance tracking through a CDNI
> environment, a more modest but achievable goal may be for the CDNI Logs to
> include a few more perf related fields that can be directly measured by the
> Surrogate. I believe the DASH performance specs include several reference
> points for measurement on the client side and the lowest level reference
> point relates to transport/delivery: perhaps we could look at those and see
> if we could extract a few meaningful perf metrics for which we could define
> the mirror server-side metric. And allow inclusion of those in our CDNI
> logs.
>
>  Makes sense ?
>
>  Thanks
>
>  Francois
>
>
>  If it is the CDN who gets the reports and given that the uCDN delegates
> to the dCDN (say due to limited capacity/footprint), it is less likely that
> the uCDN is the reported target, but instead the uCDN. What do you think?
>
> Richard
>
> CDNi mailing [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>https://www.ietf.org/mailman/listinfo/cdni
>
>
>
> Checked by AVG - www.avg.com
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 6 Aug 2012 13:10:43 +0100

Richard,

On 1 Aug 2012, at 06:33, Y. Richard Yang wrote:

> Hi all,
> 
> As suggested by Francois during the meeting today, here are some comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular HTTP Log Fields (Sec. 2.2):
> 
> - We may Client Port in addition to Client IP;
> 
> - About request parameters encoded in message body. In particular, some request parameters (URI, for example, for the purpose of hiding) may be encoded in the message body of a POST message;

I'm not convinced the dCDN should start trying to interpret & parse the content type of message bodies to try to extract additional logging parameters.

Ben

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 06 Aug 2012 08:57:18 -0700

Hi Ben,

> I'm not convinced the dCDN should start trying to interpret & parse the content type of message bodies to try to extract additional logging parameters.
What I had in mind was to parse the content id. One way to indicate a 
stream is
http://www.example.com/vod?vid=123456

but I know CSPs who hide the vid in POST (not visible in browser)

Hence, the video id needs to be extracted from the message body.

Does this make sense to you?

Richard

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 6 Aug 2012 12:13:04 -0400

Hi Richard,

> http://www.example.com/vod?vid=123456

Is it the CDN that is implementing this service, or the CSP?

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Y.
> Richard Yang
> Sent: Monday, August 06, 2012 11:57 AM
> To: Ben Niven-Jenkins
> Cc: [email-masked]
> Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-
> 01.txt
> 
> Hi Ben,
> 
> >> As suggested by Francois during the meeting today, here are some
> comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular HTTP
> Log Fields (Sec. 2.2):
> >>
> >> - About request parameters encoded in message body. In particular, some
> request parameters (URI, for example, for the purpose of hiding) may be
> encoded in the message body of a POST message;
> > I'm not convinced the dCDN should start trying to interpret & parse the
> content type of message bodies to try to extract additional logging
> parameters.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 06 Aug 2012 09:51:42 -0700

Hi Kevin,

>> http://www.example.com/vod?vid=123456
The setting is that www.example.com points to uCDN.com who then directs 
to dCDN.com. A setting is that the vid is encoded in a hidden field of a 
form on a web page. The CDN(s) must parse the message body to extract 
the vid field. Hence, it is a service that is provided by the CDN (parse 
the body) by working together with the CSP (use a form).

Thanks.

Richard

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 6 Aug 2012 13:08:00 -0400

Hi Richard,

  So assuming the CSP and the CDN have some agreement that the CDN is going
  to provide this translation service, wouldn't the translation result in
  some kind of actual content URI?  It would seem that the translation could
  be abstracted from the content delivery and the actual content URI could
  be used for the rest of the delivery processing?

thanx.

--  Kevin J. Ma

> From: Y. Richard Yang [mailto:[email-masked]]
> Sent: Monday, August 06, 2012 12:52 PM
> To: Kevin J Ma
> Cc: Y. Richard Yang; Ben Niven-Jenkins; [email-masked]

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 06 Aug 2012 11:13:02 -0700

Hi Kevin,

You may consider that there is a translation process. Consider this example:

<HTML>
  <BODY>
   <FORM METHOD="POST" ACTION="//vod/">
...
    <INPUT TYPE="hidden" NAME="vid" VALUE="123456">
   </FORM>
  </BODY>
</HTML>

The URI may be logged as only /vod, and the active page will need to 
parse the standard input (STDIN) to parse the vid. The fix is that the 
log format should define the "semantics" one (i.e., including the video 
id), instead of the only /vod URI, without indicating the video id. Does 
this make sense to you?

Thanks!

Richard