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

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 4 Mar 2012 20:28:54 +0000

Authors,

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.

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.

3) Although you do not yet specify a particular log digest format it would seem reasonable to me to reuse the W3C model (http://www.w3.org/TR/WD-logfile.html) and also to use the W3C convention for log field prefixes such as c-, cs-, etc.

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.

Ben

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 7 Mar 2012 13:42:35 -0800

Hi Ben. Thanks for your feedback. My comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Niven-Jenkins
Sent: Sunday, March 04, 2012 12:29 PM
To: [email-masked]
Subject: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

Authors,

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. But in general, the log fields contain
information that are pertinent to an ABR content.

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.

3) Although you do not yet specify a particular log digest format it
would seem reasonable to me to reuse the W3C model
(http://www.w3.org/TR/WD-logfile.html) and also to use the W3C
convention for log field prefixes such as c-, cs-, etc.

KL> Right, the specific format is not specified. This reference seems
reasonable to me.

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 7 Mar 2012 22:27:00 +0000

Kent,

On 7 Mar 2012, at 21:42, Kent Leung (kleung) wrote:

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

> But in general, the log fields contain

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.

> customized log format provided by uCDN. In a sense, this is a superset

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

> 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

> I haven't discussed this in finer details with Francois yet. It

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 8 Mar 2012 15:48:37 -0800

Comments below.

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

> 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

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.

> customized log format provided by uCDN. In a sense, this is a superset

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

> KL> I think the intent is to summarize succinctly the ABR session in
the

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 13 Mar 2012 19:39:10 +0100

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

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 22 Mar 2012 09:00:02 -0700

Tracking requirements from CDNI Interface drafts. Based on the discussion for draft-lefaucheur-cdni-logging-delivery, we need some inputs from the WG on the CDNI Logging requirements.

Options for logging requirements for ABR content:
 
	1) Event-Based Logging shall be supported [HIGH], Segment-Based Logging should be supported [MED], and Summary-Based Logging may be supported [LOW]. 

	Reason: The dCDN needs to be aware of ABR content and should log delivery with the ABR-related fields. ABR is expected to be a very common delivery format and requires some form of log compression over very voluminous per-segment logging. ABR content needs to be supported by CDNs. Related requirement is "GEN-14  [HIGH] The CDNI solution shall support HTTP Adaptive Bit Rate (ABR) content."

OR

	2) Event-Based Logging, Segment-Based Logging, and Summary-Based Logging may be supported [LOW]. 
		
	Reason: Eliminate the need for dCDN to be aware of ABR content. For example, dCDN 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 to be overkill.

Thoughts?

Kent

-----Original Message-----
From: Francois Le Faucheur (flefauch) 
Sent: Tuesday, March 13, 2012 11:39 AM
To: Kent Leung (kleung); Niven-Jenkins Ben
Cc: Francois Le Faucheur (flefauch); [email-masked]; Mahesh Viveganandhan (mvittal)
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

Ben, Kent,

<snip>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 23 Mar 2012 02:35:38 +0000

Kent,

Comments inline

> fields specified in this section.

I don't agree with this logic. If what is being delivered is ABR content then it is ABR content regardless of whether the dCDN is aware or not that what it is delivering is ABR content.

> content delivery? No. I sense that I'm still missing your point.

If the content is non-ABR the ABR specific fields are obviously not useful but that's not the point.

What the text in the draft is saying is if the *content* that is delivered is ABR then the dCDN MUST support logging the ABR specific fields.

What it does not say (which might be what you actually mean) is that if the *content* that is delivered is ABR and if the dCDN is *aware that it is ABR* then it MUST support logging the ABR specific fields.

Anyway I think we're approaching this from the wrong angle. I think we should agree what needs to be logged for individual HTTP deliveries in general (whether or not they are ABR) where in the case of ABR a single delivery corresponds to a single ABR segment request/response. That is the base level absolutely required for interoperability.

If, after that, the group decides to define an optimisation in addition (or as a replacement in certain cases) for ABR then that is something we can look at.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 23 Mar 2012 03:02:36 +0000

Francois,

On 13 Mar 2012, at 18:39, Francois Le Faucheur wrote:

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

I agree that ABR produces large volumes of log entries when the dCDN creates a log entry per HTTP delivery (HTTP response).

I agree that compressing those logs in some way before distributing to uCDNs would be more efficient that not doing so provided the compression does not result in the loss of information.

> (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). 

Some of the confusion from my side might be that I'm not entirely certain what you are proposing the logging behaviour of the dCDN should be, i.e. are you arguing that in the case where the dCDN is "ABR aware":

1) We log every single HTTP delivery (HTTP response) individually (let's ignore whether the format is just "plain" HTTP log fields or "plain" HTTP log field plus your proposed Segment-Based log fields) and we produce Event-Based Logs

2) We just produce Event-Based Logs

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

Except that if all the dCDN produces for ABR content is an Event-Based Log, the proposed Event-Based Log does lose information compared to a "plain" HTTP delivery log. For example the proposed Event-Based Log does not contain all the URLs that were requested by the client, or the timings of the individual requests/responses, or the sizes of the individual responses or the cache disposition/Action (TCP_HIT, TCP_MISS, etc.) of the individual responses.

Furthermore, the draft as written does say that, for example an Event-Based Log entry contains a Cache Disposition/Action field but the semantics of that field are not clear, i.e. a single event potentially consists of a >1 HTTP delivery (HTTP response) and in the case where some of those deliveries/responses were hits and others were misses what is the correct value to log? The semantics of several other fields in the Event-Based Log are also unclear.

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

I will post something to the mailing list when I get a chance.

Ben

---

From: Stef van der Ziel <[email-masked]>
Date: Fri, 23 Mar 2012 11:27:03 +0100

Hi,

One of the fundamental problems of ABR technologies in general is lack of true sessions. It's stateless technology.

Session control and session logging are lost. Delivery nodes simply log every segment request without any correlation. 
Making it impossible to 100% reconstruct a true user session in reports. 

A side effect is that the number of log entries explode, stressing log processing and analytics tools. We have seen many CDNs cope with log processing problems after their content customers switched to ABR.

To resolve both problems we have worked with various delivery vendors for caching / reverse proxy services / appliances to keep track of actual sessions. They can do this by inserting a session ID to the manifest and subsequent chunk access logs and then have a separate log processing service to aggregate all logs back into a single session log. Alternatively (and preferred) their delivery software or appliance aggregates these into a true session access log itself. It scales better and this approach is less prone to errors.

(So the claim that any reverse proxy can be used for ABR is false in real life scenarios since off the shelves proxies and caches don't have this feature).

uCDNs will need to know whether dCDNs support session logging for ABR content. Since this is a must have requirement for uCDNs, analytics providers and content providers. 

If the dCDN does not support this feature then the uCDN will not use the dCDN. uCDNs and their content providers will not accept bulks of logs without any correlation to sessions and will not accept educated guessed session logs but demand actual, 100% exact session information based on access logs. Their business case depends on this.

Therefore I would like to see true ABR session logs this mandatory, or at least a preferred option, that should be shared via capabilities exchange. 

We also have some ideas around instructing clients about sessions so clients can switch mid-stream between mulitple delivery nodes and multiple CDNs while keeping the CDNs abilities to track actual user sessions. But that is a second topic I guess :)

Hope this input helps.

Best Stef

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Sun, 25 Mar 2012 03:54:14 -0700

Hi Stef. So would you prefer that dCDN is required to support session
state for ABR content to participate in CDNI OR that CDNI interfaces
provide information elements (e.g. RRI capability advertisement,
optional Metadata/Logging ABR-related fields) that allows dCDN to be a
member of CDNI without being ABR-aware? I think that's the decision that
we need to make. From a requirement's perspective #1 or #2 below, or
another option?

Kent

-----Original Message-----
From: Stef van der Ziel [mailto:[email-masked]] 
Sent: Thursday, March 22, 2012 9:34 AM
To: Kent Leung (kleung)
Cc: <[email-masked]>
Subject: Re: [CDNi] CDNI Requirements for ABR content

One of the fundamental problems of ABR is lack of true sessions. Session
control and session logging is lost. Delivery nodes simply log every
segment request without any correlation. Making it impossible to 100%
reconstruct a true user session in reports. 

A side effect is that the number of log entries explode, stressing log
processing and analytics tools.

To resolve both problems we ask delivery vendors for caching / reverse
proxy services to keep track of actual sessions, insert a session ID to
the manifest and subsequent chunk access logs and aggregating back these
into a true session access log.

(So the claim that any reverse proxy can be used for ABR is false in
real life scenarios).

uCDNs will need to know whether dCDNs support session logging for ABR
content. Since this is a must have requirement for uCDNs, analytics
providers and content providers. 

If the dCDN does not support this then the uCDN will not use the dCDN.

Hope this input helps!

Best Stef

On 22 mrt. 2012, at 17:00, "Kent Leung (kleung)" <[email-masked]>
wrote:

> Tracking requirements from CDNI Interface drafts. Based on the
discussion for draft-lefaucheur-cdni-logging-delivery, we need some
inputs from the WG on the CDNI Logging requirements.
>    1) Event-Based Logging shall be supported [HIGH], Segment-Based
Logging should be supported [MED], and Summary-Based Logging may be
supported [LOW]. 
> 
>    Reason: The dCDN needs to be aware of ABR content and should log
delivery with the ABR-related fields. ABR is expected to be a very
common delivery format and requires some form of log compression over
very voluminous per-segment logging. ABR content needs to be supported
by CDNs. Related requirement is "GEN-14  [HIGH] The CDNI solution shall
support HTTP Adaptive Bit Rate (ABR) content."
>    Reason: Eliminate the need for dCDN to be aware of ABR content. For
example, dCDN 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 to be overkill.
> Subject: Re: [CDNi] Comments on
draft-lefaucheur-cdni-logging-delivery-00
> 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). 
> 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.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Sun, 25 Mar 2012 03:56:25 -0700

<snip>

Therefore I would like to see true ABR session logs this mandatory, or
at least a preferred option, that should be shared via capabilities
exchange. 

KL> OK. Your vote would be #1 then. Thanks for your inputs.

Kent

<snip>

---

From: <[email-masked]>
Date: Mon, 26 Mar 2012 10:23:34 +0200

Hi Kent,

About the tagging as "High" of Event-Based Logging support, I would like to understand what it implies 
- for the CDN and 
- for the client. 

I see the following differences between Event-Based Logging and "file-based logging":

- Session: I am not an expert of all adaptive streaming flavors; do existing clients provide a usable session id to the server?
- other service level information: 
	# Manifest-uri: could the CDN derive it from the session data?
      # Content-id: How could the CDN derive this information: From the content URL? From the session data? Other?
      # Representation: How could the CDN derive this information: From the content URL? From the session data? 

About the tagging as "Med" of segment based logging, I would also like to understand the impact on the CDN/client:
- the CDN sees the chunk requests (except the ones served by a caching-proxy or the browser cache). So I think this logging format is not more complex than event based logging for the client (it does not have to send specific information). For the CDN, the support of this format only requires the additional ability to:
	- understand the URL formats to detect the representation changes 
	- detect session ends?

Best regards,

Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Kent Leung (kleung)
Envoyé : jeudi 22 mars 2012 17:00
À : [email-masked]
Objet : [CDNi] CDNI Requirements for ABR content

 

OR

Thoughts?

Kent

-----Original Message-----
From: Francois Le Faucheur (flefauch) 
Sent: Tuesday, March 13, 2012 11:39 AM
To: Kent Leung (kleung); Niven-Jenkins Ben
Cc: Francois Le Faucheur (flefauch); [email-masked]; Mahesh Viveganandhan (mvittal)
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

Ben, Kent,

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 26 Mar 2012 08:09:09 -0700

Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So the question is only pertinent for the CDN. The methods for CDN to associate delivery of contents for the ABR session are based on cookie or URI tag (BTW, client just passes this info back to the CDN). Also, CDN needs to understand the manifest file (for HLS/HDS/HSS) to determine the abr-protocol, representation, manifest-uri, and content-id.

Both Event-Based Logging and Session-Based Logging require CDN to understand the ABR content type. So the implications or impact to the CDN is basically the same for either logging mode. For file-based logging, the CDN treats each content delivery as a file and unaware that it is really a segment/chunk/fragment of the whole content. There's no knowledge that there is a manifest file or different representations or when representation changed.

I believe the reason for Event-Based Logging as [HIGH] and Session-Based Logging as [MED] is the expectation that most of the content for the ABR session will be delivered at a steady rate after the initial buffering.

Does that answer your questions?

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 26, 2012 1:24 AM
To: Kent Leung (kleung); [email-masked]
Subject: RE: [CDNi] CDNI Requirements for ABR content

Hi Kent,

Best regards,

Gilles

-----Message d'origine-----

 

OR

Thoughts?

Kent

-----Original Message-----
From: Francois Le Faucheur (flefauch) 
Sent: Tuesday, March 13, 2012 11:39 AM
To: Kent Leung (kleung); Niven-Jenkins Ben
Cc: Francois Le Faucheur (flefauch); [email-masked]; Mahesh Viveganandhan (mvittal)
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

Ben, Kent,

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 26 Mar 2012 15:25:58 +0000

Hi Gilles/Kent/all,

It seems to me that the question we keep getting back to is whether the CDN is aware of ABR content (and if we want to require a CDN to be aware of this). This question will probably also come up when discussing other interfaces (especially metadata and request routing).

I therefore suggest that we first discuss the high-level requirements/assumptions regarding ABR/HAS and CDNI, come up with some guidelines for how the CDNI interfaces should deal with ABR/HAS, and then apply these guidelines to the various interfaces (such as in this case the logging interface).

I wrote a draft for initiating such a discussion, see http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are welcome.

Best regards,

Ray

________________________________________
From: [email-masked] [[email-masked]] on behalf of Kent Leung (kleung) [[email-masked]]
Sent: Monday, March 26, 2012 5:09 PM
To: [email-masked]; [email-masked]
Subject: Re: [CDNi] CDNI Requirements for ABR content

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 26, 2012 1:24 AM
To: Kent Leung (kleung); [email-masked]
Subject: RE: [CDNi] CDNI Requirements for ABR content

Hi Kent,

Best regards,

Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Kent Leung (kleung)
Envoyé : jeudi 22 mars 2012 17:00
À : [email-masked]
Objet : [CDNi] CDNI Requirements for ABR content

OR

Thoughts?

Kent

-----Original Message-----
From: Francois Le Faucheur (flefauch)
Sent: Tuesday, March 13, 2012 11:39 AM
To: Kent Leung (kleung); Niven-Jenkins Ben
Cc: Francois Le Faucheur (flefauch); [email-masked]; Mahesh Viveganandhan (mvittal)
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

Ben, Kent,

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 26 Mar 2012 20:18:26 -0700

Hi Ray. Yes, that is the crux of the matter. Your writeup captured many points to consider. I appreciate the terminology section so we can use the same language in the discussions.

Do you have a specific position on this? We can await your presentation and gather some general consensus in the CDNI session this week.

Kent

-----Original Message-----
From: Brandenburg, R. (Ray) van [mailto:[email-masked]] 
Sent: Monday, March 26, 2012 8:26 AM
To: Kent Leung (kleung); [email-masked]; [email-masked]
Subject: RE: [CDNi] CDNI Requirements for ABR content

Hi Gilles/Kent/all,

Best regards,

Ray

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 26, 2012 1:24 AM
To: Kent Leung (kleung); [email-masked]
Subject: RE: [CDNi] CDNI Requirements for ABR content

Hi Kent,

Best regards,

Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Kent Leung (kleung)
Envoyé : jeudi 22 mars 2012 17:00
À : [email-masked]
Objet : [CDNi] CDNI Requirements for ABR content

OR

Thoughts?

Kent

-----Original Message-----
From: Francois Le Faucheur (flefauch)
Sent: Tuesday, March 13, 2012 11:39 AM
To: Kent Leung (kleung); Niven-Jenkins Ben
Cc: Francois Le Faucheur (flefauch); [email-masked]; Mahesh Viveganandhan (mvittal)
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

Ben, Kent,

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 27 Mar 2012 08:10:54 +0200

Ray, Larry, Kent,

> Do you have a specific position on this? We can await your presentation and gather some general consensus in the CDNI session this week.

I also believe there is useful definitions/terminology/discussion in draft-brandenburg-cdni-has-00.txt that can be leveraged in the framework document.
To help reach consensus on how to do that, the Thursday session agenda includes a 10 mins slot dedicated to this exact discussion right after the presentation of draft-brandenburg-cdni-has: 
"
	• Framework (discussion on design trade-offs), draft-davie-cdni-framework-01: Larry Peterson (20 mins)
	• Models for adaptive-streaming-aware CDN Interconnection, draft-brandenburg-cdni-has-00: Ray Brandenburg (10 mins)
	• Framework (discussion on reflecting adaptive streaming design trade-offs in framework): led by Larry Peterson (10 mins)
"

But, if possible, I suggest that you guys get together and start discussing this beforehand so you can come with proposals

Thanks

Francois

---

From: "Christian Timmerer (ITEC)" <[email-masked]>
Date: Tue, 27 Mar 2012 08:41:58 +0200

Dear Ray,
  regarding terminology of segments and fragments, 3GPP- and MPEG-DASH uses segment and subsegment independent of the container format (ISOBMFF, M2TS). The former is equivalent to what you're referring to as segments and the latter is equivalent to the fragments in your draft. Furthermore, subsegments are indexed by a segment index providing the time range to byte range mapping. 

Best regards,
 -Christian

:--
:- Dr. Christian Timmerer
:- Ass.-Prof., Multimedia Communication, Alpen-Adria-Universität Klagenfurt
:- research.timmerer.com | selab.itec.aau.at | dash.itec.aau.at
------------------------------------------------------------------------------------------------------
Q: Why is this email three sentences or less? A: http://three.sentenc.es

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 27 Mar 2012 20:08:25 -0400

Hi All,

  I had a similar concern to Ben.  The loss of information in the Event-based
  logging seems undesirable from a content owner perspective.  It would seem
  that adding additional segment-based logging fields would be an easier first
  step.  Given a piece of metadata that says the content in directory X is ABR,
  then the additional fields could be added.  Implementing the event criteria
  seems more cumbersome than that.  It is also not clear to me what happens
  when the session gets delegated between different CDNs?  The events seem to
  be local-CDN specific?

thanx.

--  Kevin J. Ma

> Sent: Thursday, March 22, 2012 11:03 PM
> To: Francois Le Faucheur
> Cc: [email-masked]; Viveganandhan Mahesh
> 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.
> 
> I agree that ABR produces large volumes of log entries when the dCDN
> creates a log entry per HTTP delivery (HTTP response).
> 
> I agree that compressing those logs in some way before distributing to
> uCDNs would be more efficient that not doing so provided the compression
> does not result in the loss of information.
> 
> > (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).
> 
> Some of the confusion from my side might be that I'm not entirely certain
> what you are proposing the logging behaviour of the dCDN should be, i.e.
> are you arguing that in the case where the dCDN is "ABR aware":
> 
> 1) We log every single HTTP delivery (HTTP response) individually (let's
> ignore whether the format is just "plain" HTTP log fields or "plain" HTTP
> log field plus your proposed Segment-Based log fields) and we produce
> Event-Based Logs
> 
> > 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).
> 
> Except that if all the dCDN produces for ABR content is an Event-Based
> Log, the proposed Event-Based Log does lose information compared to a
> "plain" HTTP delivery log. For example the proposed Event-Based Log does
> not contain all the URLs that were requested by the client, or the timings
> of the individual requests/responses, or the sizes of the individual
> responses or the cache disposition/Action (TCP_HIT, TCP_MISS, etc.) of the
> individual responses.
> 
> Furthermore, the draft as written does say that, for example an Event-
> Based Log entry contains a Cache Disposition/Action field but the
> semantics of that field are not clear, i.e. a single event potentially
> consists of a >1 HTTP delivery (HTTP response) and in the case where some
> of those deliveries/responses were hits and others were misses what is the
> correct value to log? The semantics of several other fields in the Event-
> Based Log are also unclear.
> 
> > 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).
>

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 27 Mar 2012 20:08:47 -0400

Hi Kent,

  It was not clear to me why the priority of segment-based logging is not
  higher than, or at least equal to that of event-based.  Segment-based
  seems easier than event-based.  Though event-based has the arguable
  benefit of log reduction, you would already get segment-based for free?

  I would think that ABR awareness for segment-based logging could be 
  implemented simply with metadata.  Event and summary-based logging would
  require much more ABR awareness.  I might vote for option 3:

 	3) Event-Based Logging shall be supported [LOW], Segment-Based
  Logging should be supported [MED], and Summary-Based Logging may be
  supported [LOW].

thanx.

--  Kevin J. Ma

> Kent Leung (kleung)
> Sent: Monday, March 26, 2012 11:09 AM
> Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So
> the question is only pertinent for the CDN. The methods for CDN to
> associate delivery of contents for the ABR session are based on cookie or
> URI tag (BTW, client just passes this info back to the CDN). Also, CDN
> needs to understand the manifest file (for HLS/HDS/HSS) to determine the
> abr-protocol, representation, manifest-uri, and content-id.
> 
> Both Event-Based Logging and Session-Based Logging require CDN to
> understand the ABR content type. So the implications or impact to the CDN
> is basically the same for either logging mode. For file-based logging, the
> CDN treats each content delivery as a file and unaware that it is really a
> segment/chunk/fragment of the whole content. There's no knowledge that
> there is a manifest file or different representations or when
> representation changed.
> 
> I believe the reason for Event-Based Logging as [HIGH] and Session-Based
> Logging as [MED] is the expectation that most of the content for the ABR
> session will be delivered at a steady rate after the initial buffering.
> 
> - Session: I am not an expert of all adaptive streaming flavors; do
> existing clients provide a usable session id to the server?
>       # Content-id: How could the CDN derive this information: From the
> content URL? From the session data? Other?
> - the CDN sees the chunk requests (except the ones served by a caching-
> proxy or the browser cache). So I think this logging format is not more
> complex than event based logging for the client (it does not have to send
> specific information). For the CDN, the support of this format only
> requires the additional ability to:
> Tracking requirements from CDNI Interface drafts. Based on the discussion
> for draft-lefaucheur-cdni-logging-delivery, we need some inputs from the
> WG on the CDNI Logging requirements.
> 
> delivery with the ABR-related fields. ABR is expected to be a very common
> delivery format and requires some form of log compression over very
> voluminous per-segment logging. ABR content needs to be supported by CDNs.
> Related requirement is "GEN-14  [HIGH] The CDNI solution shall support
> HTTP Adaptive Bit Rate (ABR) content."
> 
> OR
> 
> 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).
> 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.
> <snip>
>

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 27 Mar 2012 20:09:12 -0400

Hi Ray,

  I think the draft provides a nice description of the options.
  I had a couple of comments:

  - The chunk request routing case (section 2.2.3) seems like a degenerate
    case of full locator.  It is a full URL that points to the CDN RR.  The
    result is an HTTP redirect to either a surrogate or a dCDN RR?  Though
    the format of the URL may be protocol specific, it should not be CDN
    specific, and so it does not have to be treated any differenly from any
    other full locator.  Note: skipping ahead to the questions in section
    3.2.1, I do not think that manifest files should be modified.  At least
    in the current phase, I believe content adaptation is off the table?

    Wrt to the conclusion that full/relative locators require manifest
    file rewrite (in section 3.2.1), I do not see this as the case.  In
    the worst case, it just means that delegation is not persistent,
    though that is dependent upon how the client handles redirects...

  - One of the reasons behind the metadata grouping requirements was to
    support Chunk Collections and Content Collections.  Wrt the questions
    in section 3.2.1, I think that collections make sense, and that the
    propogation of metadata could synchronize definitions of collections
    across CDNs?

thanx.

--  Kevin J. Ma

> Brandenburg, R. (Ray) van
> Sent: Monday, March 26, 2012 11:26 AM
> It seems to me that the question we keep getting back to is whether the
> CDN is aware of ABR content (and if we want to require a CDN to be aware
> of this). This question will probably also come up when discussing other
> interfaces (especially metadata and request routing).
> 
> I therefore suggest that we first discuss the high-level
> requirements/assumptions regarding ABR/HAS and CDNI, come up with some
> guidelines for how the CDNI interfaces should deal with ABR/HAS, and then
> apply these guidelines to the various interfaces (such as in this case the
> logging interface).
> 
> I wrote a draft for initiating such a discussion, see
> http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are
> welcome.
> 
> Best regards,
> 
> Ray
> 
> 
> 
> 
> 
> 
>         Reason: Eliminate the need for dCDN to be aware of ABR content.
> For example, dCDN 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

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 28 Mar 2012 08:46:14 +0200

Hello Kevin,

On 28 Mar 2012, at 02:08, Kevin J Ma wrote:

>  logging seems undesirable from a content owner perspective.

With event-based, the gist of it is that if the client successfully pulls 100 consecutive segments at the same bandwidth/resolution, you generate one log-line that means exactly that ie here's teh base URI and here is the number of bytes that have been successfully delivered from there on. So you lose a tiny bit of information (eg which is at what time exactly was the 27th segment requested and completed its individual delivery) but you retain the significant information.
Which specific info are you concerned about that would get lost?

Thanks

Francois

>  It would seem

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 28 Mar 2012 07:49:44 +0000

Hi Kevin,

Thanks for your comments.

Wrt to your comment that Chunk Request Routing is a degenerate version of a Full Locator: While from a Client point of view the two options are certainly similar, I think they are actually quite different from a CDN functional perspective. The Full Locator as I defined it points to a specific file on a specific Delivery Node, which means that the client will not be redirected. The Chunk Request Routing option (we might need to choose a better name) on the other hand points to a request routing function, which means that there will definitely be a redirect. The RR function may either redirect the client to a specific delivery node in the same CDN or to another RR function in another CDN. For better understanding of some of the problems that are described later in the document, I think it is better to distinguish between these two methods. 

As for your comment that full locators and chunk request routing do not require manifest rewriting, I don't understand this. Assuming that delivery nodes are 'dumb' and don't know anything about inter-CDN request routing, and that full locators point to a specific delivery node (let's say on a uCDN), how can the Full Locator in the manifest line not be rewritten when the content is now supposed to be delivered by another CDN?

Although I agree that it is technically feasible to not rewrite Chunk Request Routing urls in the manifest, this would mean that for every chunk requested by the client, the uCDN needs to be involved (since it has to redirect the client to the dCDN). 

Finally, my personal opinion is that we shouldn't classify manifest file rewriting as content adaption in the sense that the CDNI WG shouldn't work on it. In other to provide a scalable solution for allowing the CDNI interfaces to deliver content using the various HAS protocols, we basically have two options: 1) we impose the use of Relative Locators for all content, and therefore limit the flexibility for both CDNs and Content Providers, or 2) we allow manifest file rewriting in some cases. While I agree that some content providers might consider the manifest as 'content' and therefore don't want it to be modified, this can be handled on an individual case by using relative locators in those cases.

Best regards,

Ray

________________________________________
From: Kevin J Ma [[email-masked]]
Sent: Wednesday, March 28, 2012 2:09 AM
To: Brandenburg, R. (Ray) van; Kent Leung (kleung); [email-masked]; [email-masked]
Subject: RE: [CDNi] CDNI Requirements for ABR content

Hi Ray,

thanx.

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 28 Mar 2012 09:53:11 -0400

Hi Ray,

  comment inline:

> Sent: Wednesday, March 28, 2012 3:50 AM
> To: Kevin J Ma; Kent Leung (kleung); [email-masked];
> [email-masked]
> Wrt to your comment that Chunk Request Routing is a degenerate version of
> a Full Locator: While from a Client point of view the two options are
> certainly similar, I think they are actually quite different from a CDN
> functional perspective. The Full Locator as I defined it points to a
> specific file on a specific Delivery Node, which means that the client
> will not be redirected. 

I see.  That specific aspect did not register on first read.  So, delivery node
in this example refers to a surrogate?  In that case, it is not clear to me why
the manifest would have a URL pointing at a specific delivery node (without the
assumption that the CDN has already modified the manifest)?  A content provider
who does not run their own CDN is unlikely to know about surrogates.  The URL
is more likely to be the content providers registered DNS address thats CNAMEd
to the uCDN which follows the normal request routing flow?  In the branding use
case, it is unlikely that the content provider would want URL rewrites?

thanx.

--  Kevin J. Ma

> The Chunk Request Routing option (we might need to
> choose a better name) on the other hand points to a request routing
> function, which means that there will definitely be a redirect. The RR
> function may either redirect the client to a specific delivery node in the
> same CDN or to another RR function in another CDN. For better
> understanding of some of the problems that are described later in the
> document, I think it is better to distinguish between these two methods.
> 
> As for your comment that full locators and chunk request routing do not
> require manifest rewriting, I don't understand this. Assuming that
> delivery nodes are 'dumb' and don't know anything about inter-CDN request
> routing, and that full locators point to a specific delivery node (let's
> say on a uCDN), how can the Full Locator in the manifest line not be
> rewritten when the content is now supposed to be delivered by another CDN?
> 
> Although I agree that it is technically feasible to not rewrite Chunk
> Request Routing urls in the manifest, this would mean that for every chunk
> requested by the client, the uCDN needs to be involved (since it has to
> redirect the client to the dCDN).
>
> Finally, my personal opinion is that we shouldn't classify manifest file
> rewriting as content adaption in the sense that the CDNI WG shouldn't work
> on it. In other to provide a scalable solution for allowing the CDNI
> interfaces to deliver content using the various HAS protocols, we
> basically have two options: 1) we impose the use of Relative Locators for
> all content, and therefore limit the flexibility for both CDNs and Content
> Providers, or 2) we allow manifest file rewriting in some cases. While I
> agree that some content providers might consider the manifest as 'content'
> and therefore don't want it to be modified, this can be handled on an
> individual case by using relative locators in those cases.
>
> Best regards,
> 
> Ray
> 
> 
> 
> To: Brandenburg, R. (Ray) van; Kent Leung (kleung);
> [email-masked]; [email-masked]
> > About the tagging as "Med" of segment based logging, I would also like
> to
> > understand the impact on the CDN/client:
> discussion
> common
> and

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 28 Mar 2012 10:03:34 -0400

Hi Francois,

  Ignoring possible timeliness, the individual logs include Time-to-Serve,
  and Current-Time, which are useful for assessing delivery performance.
  It is also not clear how errors are handled?  If the client gets handed
  a bunch of 403s and 404s, but still gets the content eventually, without
  triggering an event, are those still logged?  For Bytes-Transferred, if
  there were aborted requests, do those get counted as well?  Not all client
  behavior can be correlated with the simplified log.

thanx.

--  Kevin J. Ma

> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2012 2:46 AM
> To: Kevin J Ma
> Cc: Francois Le Faucheur; Ben Niven-Jenkins; [email-masked]; Viveganandhan
> Mahesh
> With event-based, the gist of it is that if the client successfully pulls
> 100 consecutive segments at the same bandwidth/resolution, you generate
> one log-line that means exactly that ie here's teh base URI and here is
> the number of bytes that have been successfully delivered from there on.
> So you lose a tiny bit of information (eg which is at what time exactly
> was the 27th segment requested and completed its individual delivery) but
> you retain the significant information.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 28 Mar 2012 15:14:54 +0000

Hi Kevin, comment inline.

Ray
Sent: Wednesday, March 28, 2012 3:53 PM

Hi Ray,

[RAY]: One situation where Full Locators are used is in cases where a particular CDN wants to divide segments across different delivery nodes (or surrogates using your terminology). For example, for efficiency reasons a CDN might want to place a certain subset of the segments on more nodes (or different nodes) than all of the other segments. In that case, having Full Locators doesn't require per-chunk request routing, while it is still possible to have this added flexibility. I agree that this does mean that the CDN (in this case the uCDN) has rewritten the manifest it received from the content provider, but that can be a bilateral agreement where the content provider does not have any problems with rewriting the manifest.

thanx.

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 28 Mar 2012 12:12:45 -0400

Hi Ray, inline:

> Sent: Wednesday, March 28, 2012 11:15 AM
> [RAY]: One situation where Full Locators are used is in cases where a
> particular CDN wants to divide segments across different delivery nodes
> (or surrogates using your terminology).

Was just trying to conform to the problem statement terminology...  ;)

> For example, for efficiency
> reasons a CDN might want to place a certain subset of the segments on more
> nodes (or different nodes) than all of the other segments. In that case,
> having Full Locators doesn't require per-chunk request routing, while it
> is still possible to have this added flexibility.

For live HLS, e.g., the manifest file is going to change every segment;
is per-chunk manifest file rewrite better than per-chunk request routing?

> I agree that this does
> mean that the CDN (in this case the uCDN) has rewritten the manifest it
> received from the content provider, but that can be a bilateral agreement
> where the content provider does not have any problems with rewriting the
> manifest.

Assuming there was a list of supported manifest formats, manifest file
rewrite may need to be fairly content aware, e.g., recognizing spliced
content which may not be in the CDN, and not modifing manifests in any
way that would upset the client, wrt recognizing newer versions or any
proprietary protocol enhancements.  Though I don't think that manifest
rewrite is a good idea, wrt CDNI, the uCDN should be redirecting in a
way that is acceptable to the dCDN.  If the parameters of the bilateral
agreement have been accepted by the dCDN, and the dCDN has advertised
that capability, then I do not see the need to distinguish the actual
format of the URL or how it is processed internally by either CDN?

> > > CDN treats each content delivery as a file and unaware that it is
> really
> > a
> > > About the tagging as "High" of Event-Based Logging support, I would
> like
> > > to understand what it implies
> > > - for the CDN and
> > > - for the client.
> > >
> > >       # Representation: How could the CDN derive this information:
> From
> > > the content URL? From the session data?
> > >
> > > De : [email-masked] [mailto:[email-masked]] De la part
> de
> > > Kent Leung (kleung)
> > >         2) Event-Based Logging, Segment-Based Logging, and Summary-
> Based
> > > Logging may be supported [LOW].
> > >
> > > be aware of that level of information and/or because the control of
> how
> > to
> > > Cc: Francois Le Faucheur (flefauch); [email-masked]; Mahesh
> Viveganandhan
> > > (mvittal)
> > > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-
> delivery-
> > 00
> > >
> > > Ben, Kent,
> > >
> > > Ben argues that ABR-aware logging should not be mandatory as it
> requires
> > > extra awareness.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 28 Mar 2012 16:24:17 +0000

Hi Kevin, see inline
Sent: Wednesday, March 28, 2012 6:12 PM

[Ray]: Agree :)

[Ray]: I agree that is questionable. However, for live content, there is usually less reason for wanting to distribute the content across different surrogates. 

[Ray]: I think as long as you only change the location of a segment, and use common formatting rules, manifest rewriting can actually be a quite simple process. 

You mention that you don't think manifest rewriting is a good idea, which I can understand. However, do you know a good alternative apart from using Relative URLs and limiting flexibility or using per-chunk RR which has scalability issues?

Furthermore, apart from request routing, there might be other reasons for wanting to do manifest rewriting, such as including CDN-specific keys/tokens. 

The way I see it, manifest rewriting is probably a necessary evil when you want to do CDN interconnection for HAS content in a scalable manner.

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 28 Mar 2012 12:56:51 -0400

Hi Ray,

  I agree that manifest rewrite is a powerful tool.  My concern is that,
  as with other types of content adaptation, there are complexities
  involved which the wg may or may not want to tackle at this time, and
  that if it is largely an intra-CDN operation, then it would be out of
  scope for CDNI?  Though, I look forward to hearing other opinions...

thanx!

--  Kevin J. Ma

> Sent: Wednesday, March 28, 2012 12:24 PM
> > I see.  That specific aspect did not register on first read.  So,
> delivery
> > node
> > who does not run their own CDN is unlikely to know about surrogates.
> The
> > URL
> [Ray]: I agree that is questionable. However, for live content, there is
> usually less reason for wanting to distribute the content across different
> surrogates.
>
> > I agree that this does
> [Ray]: I think as long as you only change the location of a segment, and
> use common formatting rules, manifest rewriting can actually be a quite
> simple process.
>
> You mention that you don't think manifest rewriting is a good idea, which
> I can understand. However, do you know a good alternative apart from using
> Relative URLs and limiting flexibility or using per-chunk RR which has
> scalability issues?
>
> Furthermore, apart from request routing, there might be other reasons for
> wanting to do manifest rewriting, such as including CDN-specific
> keys/tokens.
>
> The way I see it, manifest rewriting is probably a necessary evil when you
> want to do CDN interconnection for HAS content in a scalable manner.
>
> > thanx.
> >
> > --  Kevin J. Ma
> >
> > >     specific, and so it does not have to be treated any differenly
> from
> > > any
> > > > apply these guidelines to the various interfaces (such as in this
> case
> > > the
> > > > logging interface).
> > > >
> > > > From: [email-masked] [[email-masked]] on behalf of
> Kent
> > > > Leung (kleung) [[email-masked]]
> > > > associate delivery of contents for the ABR session are based on
> cookie
> > > or
> > > > understand the ABR content type. So the implications or impact to
> the
> > > CDN
> > > > is basically the same for either logging mode. For file-based
> logging,
> > > the
> > > > I see the following differences between Event-Based Logging and
> "file-
> > > > based logging":
> > > >
> > > > For example, dCDN is acting in a pure HTTP reverse proxy mode and
> may
> > > not
> > > > 1) level of requirement for support of HTTP Adaptive Streaming
> Logging
> > > > Session (ie ABR-aware logs):
> > > > format and Event-Based Logging format be mandatory. But come to
> think
> > of

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 30 Mar 2012 05:24:41 -0400

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

> Francois Le Faucheur
> Sent: Tuesday, March 13, 2012 2:39 PM
> 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.
> 	* 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 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).
> 
>

---

From: Roy Peterkofsky <[email-masked]>
Date: Fri, 30 Mar 2012 11:33:40 -0700

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)

-- 
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: Kevin J Ma <[email-masked]>
Date: Fri, 30 Mar 2012 14:51:15 -0400

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)

Hi Francois,

thanx.

--  Kevin J. Ma

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of

Francois Le Faucheur

Cc: [email-masked]<mailto:[email-masked]>; Viveganandhan Mahesh

Ben, Kent,

1) level of requirement for support of HTTP Adaptive Streaming Logging

from my viewpoint).

Ben argues that ABR-aware logging should not be mandatory as it requires

extra awareness.

fields.

 * retain the notion of Format Types (e.g Delivery_HTTP,

Delivery_Adaptive_Event, ...)

3) encoding format:

I also agree the W3C extended log format is a good base candidate to look

at.

just fine).

Francois

Comments below.

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

Of

fields such as abr-protocol, representation, manifest-id and

content-id

control of how to identify those fields is owned by the CSP and none

of

awareness in dCDN to recognize that the many HTTP requests correspond

to

downstream CDN should use. Rather than define a set of specific

formats,

we could allow the upstream CDN to specify CDNI metadata indicating

the

that's needed without extraneous fields. This can be accomplished with

a

of selective fields.

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

delivery log lines but by itself appears to give equivalent

compression

compared to what gzip alone achieves (in some cases averaging as

little

KL> I think the intent is to summarize succinctly the ABR session in

the

logging.

files we require.

Ben

Kent

optimization in delivery of either session-based or event-based

logging.

Kent

Ben

CDNi mailing list

[email-masked]<mailto:[email-masked]>

CDNi mailing list

[email-masked]<mailto:[email-masked]>

CDNi mailing list

[email-masked]<mailto:[email-masked]>

CDNi mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Roy Peterkofsky <[email-masked]>
Date: Fri, 30 Mar 2012 12:09:13 -0700

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:
> *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 
> 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.
>
> 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:
>
>     From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of
>
>     Francois Le Faucheur
>
>     Cc:[email-masked]  <mailto:[email-masked]>; Viveganandhan Mahesh
>
>             From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf
>
>         Of
>
>               
>
>             [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
> [email-masked]  <mailto:[email-masked]>
> www.skytide.com <http://www.skytide.com>
> (510) 250-4284
>

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 30 Mar 2012 16:16:22 -0400

> I think the point you are getting to maybe refers to the steps involved
> in transferring rather than capturing the log data?

No.  As I said, if the dCDN does not typically store a given piece of data,
it cannot log it, nor can it be queried for it.  Telling the dCDN that a
specific piece of information may be required for a given content item is
fairly orthogonal to how you later retrieve that information.

From: Roy Peterkofsky [mailto:[email-masked]]
Sent: Friday, March 30, 2012 3:09 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

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

--  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]<mailto:[email-masked]>; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

Hi Francois,

thanx.

--  Kevin J. Ma

-----Original Message-----

Francois Le Faucheur

Ben, Kent,

from my viewpoint).

extra awareness.

fields.

3) encoding format:

at.

just fine).

Francois

Comments below.

-----Original Message-----

Of

content-id

of

to

formats,

the

a

of selective fields.

dCDN.

over

have

compression

little

the

logging.

files we require.

Ben

Kent

logging.

Kent

Ben

CDNi mailing list

CDNi mailing list

CDNi mailing list

CDNi mailing list