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

From: <[email-masked]>
Date: Thu, 5 Apr 2012 10:10:45 +0200

Hi Roy,

Thanks for bringing this useful discussion to the list. We have started to tackle these points and to describe the Logging Framework in http://tools.ietf.org/html/draft-bertrand-cdni-logging-00. Right now we are extending it to propose transactions for the Logging format negotiation and the Logging delivery.

Cheers,

Gilles

De : [email-masked] [mailto:[email-masked]] De la part de Roy Peterkofsky
Envoyé : vendredi 30 mars 2012 21:09
À : Kevin J Ma
Cc : [email-masked]; Viveganandhan Mahesh
Objet : Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

I think that getting into the mechanics of how a dCDN would capture data about transactions it delivers is not central to the development of interfaces to other CDNs, as long as the interface standards don't demand anything that is infeasible.  I think the point you are getting to maybe refers to the steps involved in transferring rather than capturing the log data?  For example a true pull-oriented query interface would actually require all participating dCDNs to store the log data for at least some standardized retention time so that it would be available for uCDNs to pull out.  Another option would be that uCDNs could send messages to dCDNs -- in advance of actual delivery transactions -- specifying what data (and in what form) the uCDN wants to receive about ensuing transactions.  That messaging could include conditional branches such as IF you are ABR-aware then send me data as follows but IF NOT then send me data in this other way.

The upshot of the above would be that the standards to be produced would include:

1) what data elements and levels of aggregation should a dCDN be required to make available  to uCDNs, in both ABR-aware and non-ABR-aware circumstances
2) if a dCDN chooses to make additional data elements and/or levels of aggregation available, above and beyond the requirements, how should they communicate this availability to uCDNs
3) what would be the means and format by which uCDNs transmit their specification of desired data to dCDNs, including both the required elements and any optional elements
4) what (if any) is the default logging/reporting to be provided by dCDNs in the absence of such communication from uCDNs
5) what should be the format of the logs/reports sent by dCDNs in response to the communciation sent by the uCDNs about their desired data elements/levels of aggregation

Working in that framework would allow most if not all of the issues that have been brought up to be addressed 

On 3/30/2012 11:51 AM, Kevin J Ma wrote: 

Hi Roy,

> The discussion of possibly allowing the uCDN to specify (via

> metadata transfer or other means) which log fields or formats it

> wishes to receive actually, I feel, calls for stepping back and

> reviewing whether we should have purely a logging interface or more

> of a reporting or query interface 

Regardless of how the data is retrieved (push or pull), the dCDN

needs to know whether or not it needs to extract the data.  It may

be that the dCDN does not automatically extract the X-foo header,

and the metadata specifies that the X-foo header is desired.  I

think that would be needed even if it was a query interface?

--  Kevin J. Ma

From: Roy Peterkofsky [mailto:[email-masked]] 
Sent: Friday, March 30, 2012 2:34 PM
To: Kevin J Ma
Cc: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; [email-masked]; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

It sounds like there is clearly a need to have standards for logging that cover two different scenarios:

1) Where the dCDN is ABR-aware and can produce session-level logs
2) Where the dCDN is not ABR-aware and can only produce transaction-level (event- or fragment-level) logs

I believe that the second scenario is required while the first is more optional/nice-to-have.  It would certainly be better to have it than not although I think it would be by far the less common situation.

The discussion of possibly allowing the uCDN to specify (via metadata transfer or other means) which log fields or formats it wishes to receive actually, I feel, calls for stepping back and reviewing whether we should have purely a logging interface or more of a reporting or query interface.  That would, I imagine, allow the uCDN to specify:

1) what transactions do I want data about (specified by date range and possibly other filter criteria)
2) what attributes and measures do I want to receive in my data
3) what level of aggregation do I want the data at (including for example, at the session level or individual file level)

On 3/30/2012 2:24 AM, Kevin J Ma wrote: 

Hi Francois,
 
  Wrt a flexible set of log fields, I think that it is a great idea, and
  it would be great if we could use metadata to specify log formats for
  specific content items or sets of content items.  It is useful for both
  content-specific logging (e.g., ABR), as well as client-specific logging
  (e.g., X-* headers).  For the W3C format, a separate log file for each
  format could result in a lot of files?  Would aggregation cover that?
 
thanx.
 
--  Kevin J. Ma

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On Behalf Of
	Francois Le Faucheur
	Sent: Tuesday, March 13, 2012 2:39 PM
	To: Kent Leung (kleung); Niven-Jenkins Ben
	Cc: [email-masked]; Viveganandhan Mahesh
	Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00
	 
	Ben, Kent,
	 
	Trying to extract the key points from the thread:
	 
	1) level of requirement for support of HTTP Adaptive Streaming Logging
	Session (ie ABR-aware logs):
	This is a valid question.
	The I-D proposes that some form of ABR-aware logging be mandatory. The
	rationale is that ABR is expected to be a very common delivery format and
	requires some form of log compression over very voluminous per-segment
	logging. (BTW the I-D currently proposes that both Segment-Based Logging
	format and Event-Based Logging format be mandatory. But come to think of
	it, having only Event-Based Logging format mandatory would be sufficient
	from my viewpoint).
	Ben argues that ABR-aware logging should not be mandatory as it requires
	extra awareness.
	To get more input, I'd propose we move that requirement level discussion
	to the cdni-requirements document, and have the logging I-D only talks
	about what such logs would look like.

	2) flexible set of log fields:
	I agree it is a good idea to allow the uCDN to customize the set of log
	fields reported by a dCDN for delivery. I was thinking that we'd start
	with defining a few "fixed" set of fields and then later add the
	customization, but perhaps we can start directly with customizable sets of
	fields.
	To do that, I'd propose to:
	 * retain the notion of Format Types (e.g Delivery_HTTP,
	Delivery_Adaptive_Event, ...)
	 * define a set of candidate fields in each Format Type
	 * have uCDN signal in Metadata interface the desired Format Type +
	set of fields needed (ie a subset of the set of candidate fields)
	 * have dCDN explicitly indicate inside each log file (eg in File
	Header), the Format Type and the set of fields actually included
	 * define handling of potential capability mismatch situations if any
	(eg1 uCDN requests a field that is not supported by dCDN if we allow that,
	eg2 dCDN requests a format type that is not supported by dCDN).

	3) encoding format:
	I also agree the W3C extended log format is a good base candidate to look
	at.

	4) summarization of Logging info for Adaptive Streaming delivery
	I believe some form of summarization is required. The Event-Based Logging
	seems like a nice sweet-spot because it achieves a high summarization gain
	without losing any info (ie any change in bandwidth/quality is logged).
	The I-D suggests we may be able to come up with another interesting sweet-
	spot (Summary-Based Log) providing a huge summarization gain at the cost
	of losing some details, but does not yet specify this.
	Ben, it'd be interesting to provide a brief write-up on the summarization
	approach you mention so we can evaluate it (an email to the list woudl be
	just fine).

	Thanks for the discussion.
	 
	Francois

	On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote:

		Comments below.

			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] On Behalf

		Of

			Some comments on draft-lefaucheur-cdni-logging-delivery-00.
			 
			1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1
			(Event Based Log Triggers) you mandate support for a number of log
			fields such as abr-protocol, representation, manifest-id and

		content-id

			that a downstream CDN may have no ability to generate, for example
			because the downstream CDN is acting in a pure HTTP reverse proxy mode
			and may not be aware of that level of information and/or because the
			control of how to identify those fields is owned by the CSP and none

		of

			CDNs may have visibility of that mapping information.
			 
			Such a requirement to force CDNs and CDNI in general to require such
			mappings seems overkill to me.
			 
			KL> As stated, "... such aggregation requires a degree of application
			awareness in dCDN to recognize that the many HTTP requests correspond

		to

			a single video." So the premise is that the dCDN knows that it's
			delivering ABR content. In some cases, it's possible that the
			representation may not be known.

		And my point is that I don't think that premise holds true and reality
		is the opposite, i.e. in general the dCDN will not know what it's
		delivering and only some dCDNs will have the application awareness to
		produce the log fields you suggest.
		 
		KL> Hmm, if the dCDN is not aware about the ABR session, then Section
		3.2 would not apply since the dCDN considers itself to be delivering
		non-ABR content.  Non-ABR content delivery does not require the log
		fields specified in this section.

			But in general, the log fields contain
			information that are pertinent to an ABR content.

		I am not exactly sure what you mean by this. I agree the fields you
		suggest would be useful but I don't think having the application
		awareness to generate them should be a mandatory requirement for
		interoperability as suggested by section 3.2
		 
		  An implementation of the CDNI Logging interface MUST support logging
		  for delivery of content using HTTP adaptive streaming in the Segment-
		  Based Logging format and the Event-Based Logging format, and MAY
		  support logging in the Summary-Based Logging format.
		 
		KL> Are these fields in Sect 3.2 useful or applicable for non-ABR
		content delivery? No. I sense that I'm still missing your point.

			2) In section 6 you propose an additional requirement to allow an
			upstream CDN to indicate through CDNI metadata the log format the
			downstream CDN should use. Rather than define a set of specific

		formats,

			we could allow the upstream CDN to specify CDNI metadata indicating

		the

			specific log fields it is interested in receiving. The upstream CDN
			could then tailor what it asks for according to what it requires and
			avoid the transfer of log fields that it does not need.
			 
			KL> Agree that it's useful for uCDN to request only the information
			that's needed without extraneous fields. This can be accomplished with

		a

			customized log format provided by uCDN. In a sense, this is a superset
			of selective fields.

		That is another approach which would probably make life easier for the
		dCDN.

			4) If the motivation for summary/aggregated log lines is a concern

		over

			the volume of data that needs to be transferred then in Velocix we

		have

			done some experiments on using an alternative lookup table based
			structure for log lines that retains all the verbosity of the original
			delivery log lines but by itself appears to give equivalent

		compression

			to gzip and combined with gzip reduces the size significantly when
			compared to what gzip alone achieves (in some cases averaging as

		little

			as 13 bits per complete log line).
			 
			If the volume of logs to be transferred is a concern and there is
			interest in investigating this approach further I can write-up more
			details either in a separate draft or as a section in
			draft-lefaucheur-cdni-logging-delivery.
			 
			KL> I think the intent is to summarize succinctly the ABR session in

		the

			logging.

		I think they're two separate things. If we're worried about the volume
		of data our experiments show that can be significantly reduced using
		structured log files with lookup tables. That technique is applicable
		regardless of the actual fields in a log file.
		 
		Whether we require ABR session summary information to be logged is a
		separate discussion to how we might optimise the structure of any log
		files we require.
		 
		Ben
		 
		KL> Sure, I think we can discuss more on this when Francois is available
		as I'm not clear on his thoughts.
		 
		Kent

			I haven't discussed this in finer details with Francois yet. It
			seems to me that the compression technique can be considered as
			optimization in delivery of either session-based or event-based

		logging.

			We can discuss this further if our goals are aligned.
			 
			Kent
			 
			Ben
			_______________________________________________
			CDNi mailing list
			[email-masked]
			https://www.ietf.org/mailman/listinfo/cdni

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

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

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

-- 
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> 

-- 
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>