Subject: Re: [CDNi] Requirement for CDNI Logs in uCDN --> dCDN direction?

From: "Kent Leung (kleung)" <[email-masked]>
Date: Sat, 23 Feb 2013 22:19:04 +0000

Hi Gilles. My comments below in "KL>".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, November 26, 2012 2:17 AM
To: Francois Le Faucheur (flefauch); STEPHAN Emile OLNC/OLN
Cc: <[email-masked]>
Subject: Re: [CDNi] Requirement for CDNI Logs in uCDN --> dCDN direction?

Hi François,

There are several use cases for providing Logging information from uCDN to dCDN. The main ones are:
- debugging
- security auditing

Quite often, both dCDN and uCDN have partial information about an event, and want to compare this information. For instance, if uCDN complains that many client requests are not served, such comparison helps establishing where the problem is located and who is responsible for that. In this case, the dCDN may for instance request the uCDN Logging information related to the HTTP redirection from uCDN to dCDN and compare this information to its own content delivery logs. 

KL> In this case, uCDN can debug the issue by obtaining the logs from dCDN and analyze that along with its logs for HTTP redirection to the dCDN. That should be sufficient to isolate the problem (e.g. redirection was not received by dCDN, dCDN could not deliver content) and identify the responsible CDN. It's still not clear to me why dCDN needs to get logs from uCDN for troubleshooting since uCDN has all the information based on its logs and the dCDN's logs? I'm not quite convinced by this example.

Another example: if content acquisition does not work, the dCDN knows which requests it has sent and the uCDN knows which ones it has received, as well as what error may have occurred during the processing of these requests. The dCDN may request uCDN's content acquisition Logging data and compare it to its own content acquisition logs.

KL> In this case, dCDN would know content acquisition requests that succeeded or failed and can log the events. Also, uCDN would know about failure in some scenarios but not all (e.g. no connection between CDNs). From the debugging perspective, it seems the practical approach is to have dCDN's log the delivery failed due to inability to acquire the content from uCDN. Again, uCDN would be able to isolate the problem by evaluating its logs along with the dCDN's logs.

Note that the need of supporting logging exchanges from uCDN to dCDN is one among several arguments in favor of using CI interface for Logging control:

[http://tools.ietf.org/html/draft-bertrand-cdni-logging-02#page-8]

"
	The rationale
   for using the Control interface for Logging Control (instead of for
   instance using the Metadata interface) includes:

   o  the Logging Control interactions typically define fairly static
      information for initializing and controlling the Logging
      interface, which matches the role of the Control Interface as
      described in [I-D.ietf-cdni-framework] and [RFC6707].

   o  the Logging Control information (specifying the Logging
      information format and scope is primarily intended to be consumed
      by the (typically fairly centralized) logical entity responsible
      for collecting intra-CDN logs, processing, filtering those and
      then exporting the relevant subset of logs/fields to the other
      CDNs.

   o  the surrogates within a given CDN are typically not expected to
      need to be aware of the specific set of fields or set of events
      that have been requested by various interconnected CDNs.  Rather
      the surrogates are likely to perform some generic logging for all
      services regardless of the peculiarities of every CDNI agreement.
      Processing (e.g. filtering, format adaptation) of the generic
      logging information generated by the Surrogates is expected to
      take place to ensure that each interconnected CDN receives the
      specific set of fields and logs it has requested through Logging
      Control.  Therefore there is no need to ensure that the Logging
      control information be easily distributable through the CDNs right
      down to surrogates.

   o  the Control interface is expected to support the capability to
      apply control at the granularity of content sets (e.g. for content
      Purge) which is required for Logging Control since it is expected
      that a CDN may require different sets of logging fields and events
      for different sets of content (e.g. because it only needs to
      perform coarse billing for a given CSP while it needs to provide
      detailed analytics for another CSP).
"

KL> I see Logging Control as a different topic from requirement for directional logging. First step is to validate the value of uCDN to dCDN direction for logging reporting. I'm not persuaded yet that there's a need. But open to others' opinions. :) 

Kent

Best regards,

Gilles

-----Message d'origine-----
De : Francois Le Faucheur (flefauch) [mailto:[email-masked]] Envoyé : jeudi 22 novembre 2012 16:20 À : STEPHAN Emile OLNC/OLN; BERTRAND Gilles OLNC/OLN Cc : <[email-masked]> Objet : Requirement for CDNI Logs in uCDN --> dCDN direction?

Emile, Gilles,

In Atlanta, there was some non-conclusive discussion on whether or not there was a strong enough requirement for passing CDNI Logging information from uCDN to dCDN.

Could you identify examples of CDNI Logging information that one may want to communicate from uCDN to dCDN?

Thanks

Francois

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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