Subject: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

From: Roy Peterkofsky <[email-masked]>
Date: Thu, 29 Mar 2012 18:11:55 -0700

First off, by way of introduction, I head product management for 
Skytide.  We are a leading supplier of CDN reporting and analytics 
software and thus a key consumer of CDN logs.  I think this gives us a 
good perspective on requirements for CDNi logging.

Secondly, I am very new to the IETF working group so I apologize if my 
comments are not in the customary or correct form for this.  I did want 
to get these to the group before you meet in Paris to discuss this 
subject area so I focused my attention on making the comments timely.

Anyway:

1) It is certainly a good idea to have a standard for transmitting log 
records that each describe an entire ABR/HAS session rather than just an 
individual file from within the session.    But we should be aware that 
there are potentially insurmountable obstacles to producing such 
records, so the standard cannot demand that ABR/HAS activity be 
always/only reported in this manner.  The obstacles that I refer to have 
to do with the fact that any entire ABR/HAS session may not be delivered 
by one single CDN, even in the absence of participation in 
interconnection/federation activities.  The fragments of a single 
session may be delivered by different CDNs because the content owner is 
using dynamic CDN-switching methods (like those of Conviva and similar 
products) or because a mobile user is constantly moving between 
different wi-fi and/or cellular networks, each of which may be connected 
to a different ISP and therefore a different CDN.  In fact, this is 
particularly relevant to certain of the working group's documented CDNi 
use cases, such as overload handling.

2) Even if all chunks of an ABR/HAS session are delivered by a single 
CDN, or even a single cache/PoP of that CDN, tracking the session as a 
whole may be difficult and require an internal aggregation point, as 
logs are usually generated at the server/device level, at which there 
would not be visibility to the entire session.

3) Obviously, if a CDN is not delivering all elements of an ABR session, 
then it cannot create log records that describe the entire session.  
Furthermore, though, there may be obstacles to determining some of the 
events or metrics that the document suggests capturing.  For example, a 
CDN that does not deliver every element of a session will not always 
deliver consecutive fragments of the session and, therefore, cannot 
generally determine if upshifts or downshifts occur.

4) These concerns would no doubt go away if some of the ABR/HAS 
optimizations discussed in draft-brandenburg-cdni-has-00 
<http://datatracker.ietf.org/doc/draft-brandenburg-cdni-has/> (Models 
for adaptive-streaming-aware CDN Interconnection) were implemented.  I 
am a bit leery of basing logging standards on the assumption that those 
will become standardized because very few CDNs (or CDN platforms) have 
those capabilities available -- even for independent CDN operations, let 
alone CDNi operations -- and because the issues discussed above (like 
content owners switching CDNs beyond the control of both the uCDN and 
dCDN) could make them impossible.  Clearly, to implement such 
optimizations would require end-to-end cooperation from the content 
provider through both CDNs and potentially even to the end user (who may 
control the software on the user agent).  That's a great vision to 
pursue but the logging standards also need to be able to accommodate the 
likely reality on the ground.

-- 
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: Francois Le Faucheur <[email-masked]>
Date: Fri, 30 Mar 2012 07:47:10 +0200

Hello Roy,

Thanks for your input. Brief comments below:

On 30 Mar 2012, at 03:11, Roy Peterkofsky wrote:
> 
> Anyway:
> 
> 1) It is certainly a good idea to have a standard for transmitting log records that each describe an entire ABR/HAS session rather than just an individual file from within the session.    But we should be aware that there are potentially insurmountable obstacles to producing such records, so the standard cannot demand that ABR/HAS activity be always/only reported in this manner. 

Noted. 

Please note that the document discussed different potential flavours of log format for adaptive: one that aimed for one entry per-session, and some that aimed at one entry-per event. Some of your points below, do not apply to the 2nd form.

Cheers

Francois

> The obstacles that I refer to have to do with the fact that any entire ABR/HAS session may not be delivered by one single CDN, even in the absence of participation in interconnection/federation activities.  The fragments of a single session may be delivered by different CDNs because the content owner is using dynamic CDN-switching methods (like those of Conviva and similar products) or because a mobile user is constantly moving between different wi-fi and/or cellular networks, each of which may be connected to a different ISP and therefore a different CDN.  In fact, this is particularly relevant to certain of the working group's documented CDNi use cases, such as overload handling.
> 
> 2) Even if all chunks of an ABR/HAS session are delivered by a single CDN, or even a single cache/PoP of that CDN, tracking the session as a whole may be difficult and require an internal aggregation point, as logs are usually generated at the server/device level, at which there would not be visibility to the entire session.
> 
> 3) Obviously, if a CDN is not delivering all elements of an ABR session, then it cannot create log records that describe the entire session.  Furthermore, though, there may be obstacles to determining some of the events or metrics that the document suggests capturing.  For example, a CDN that does not deliver every element of a session will not always deliver consecutive fragments of the session and, therefore, cannot generally determine if upshifts or downshifts occur. 
> 
> 4) These concerns would no doubt go away if some of the ABR/HAS optimizations discussed in draft-brandenburg-cdni-has-00 (Models for adaptive-streaming-aware CDN Interconnection) were implemented.  I am a bit leery of basing logging standards on the assumption that those will become standardized because very few CDNs (or CDN platforms) have those capabilities available -- even for independent CDN operations, let alone CDNi operations -- and because the issues discussed above (like content owners switching CDNs beyond the control of both the uCDN and dCDN) could make them impossible.  Clearly, to implement such optimizations would require end-to-end cooperation from the content provider through both CDNs and potentially even to the end user (who may control the software on the user agent).  That's a great vision to pursue but the logging standards also need to be able to accommodate the likely reality on the ground.
> 
> 
> -- 
> Roy Peterkofsky
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni