Subject: Re: [CDNi] OPSDIR review of draft-ietf-cdni-logging-10 [Near-Real-Time Monitoring]

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 3 Jul 2014 09:04:12 +0000

David and all,

(as a document editor)

Please see below for the resolution of the comment from David’s early Ops Review about Ner-Real-Time Monitoring:

On 16 Apr 2014, at 17:25, Francois Le Faucheur (flefauch) <[email-masked]> wrote:
>> 
>> 
>> The proposed solution generally looks good for the deferred case, but seems
>> inadequate for the near-real-time monitoring case. The document declares the
>> near-real-time support to be out of scope. 
> 
> Right.
> 
>> 
>> Given the costs in time and resources of converting between logging formats,
>> it may be really desirable to have one format that can serve both sets of
>> needs.
> 
> Agreed.
> We discussed this in the Working Group and while people agreed that was desirable, the group eventually decided to not aim for the second set of needs because there was an urgent need to serve the first set of needs, it was clear how to address it, it was not clear to our group how to address the second and there was no I-Ds submitted on the second.  
> 
>> To a large degree, the proposed format could serve both purposes;
> 
> Right. And in fact, file based format is already used in practise today in some single-CDN environment for near-real-time monitoring.
> 
>> however, there are various points in the document that specify MUST
>> requirements that would prevent using the solution for both use cases.
> 
> It woudl be great if we could clean up the document from the requirements that prevents that.
> 
>> Mostly, these requirements imply that a "file" must be fully collected
>> before sharing, and given the timeliness required by the monitoring use
>> case, waiting until a file is fully collected makes the file approach
>> unsuitable for monitoring. It can be feasible to use a logging file approach
>> for monitoring, if the log can be "tail"ed, thereby allowing the contents to
>> be passed as the collection is performed, without waiting for the file to be
>> complete.
> 
> Agreed. 
> 
> In fact, this is what teh authors had in mind when writing:
> “
> We note that implementations of the CDNI Logging interface MAY also
>   support other mechanisms to exchange CDNI Logging Files, for example
>   in view of exchanging logging information with minimum time-lag
>   (e.g., sub-minute or sub-second) between when the event occurred in
>   the dCDN and when the corresponding Logging Record is made available
>   to the uCDN (e.g., for log-consuming applications requiring extremely
>   fresh logging information such as near-real-time content delivery
>   monitoring).  Such mechanisms are for further study and outside the
>   scope of this document.
> “
> However, we did not realise that the text of 4.1.2 sort of prevents that.
> 
>> 
>> In most of the network management protocols designed by the IETF, we
>> recognize three parts - a data modeling language, data models, and a
>> protocol that can transport portions of the data model. This document
>> doesn't do a great job of keeping those separate. If the document was
>> written with such separation in mind, then the record formats would be
>> independent of how the file was going to be transported, and a logging
>> record might be able to be used with two different approaches to transport -
>> one suitable for deferred usage, where it can be expected that the file is
>> completed before transport, and another transport approach suitable for
>> near-real-time transport of individual records, possibly using a tail
>> approach for a file-based collection of records. The constraint in section
>> 4.1.2 is written in a manner that would seem to preclude a tail usage.
>> 
>> This concern might be able to be mitigated by changing some wordings in the
>> document. I think the document would be better if, rather than declaring one
>> set out of scope, it recognized the two sets of needs, and discussed how the
>> design of the data modeling language and data models could address both sets
>> of needs, while recognizing that different transport solutions might be
>> needed to meet the two sets of needs, and there might be constraints on the
>> data model designs to be suitable for both needs.
> 
> All good points.
> 
> Currently:
> 	* section 3 defines Fields, Records and FileFormat
> 	* section 4 defines a File Exchange protocol
> 
> Effectively the data model is covered by section 3, while section 4 defines a transport solution for non-real-time (with constraints that preclude near-real-time exchange via a “Tail” like approach).
> 
> In line with your suggestion above, would it work for you if we:
> 	* edited section 4 to :
> 		- define it as the Transport Protocol for non-real-time exchange (as opposed to describe it as THE file exchange protocol) 
> 	* added a very brief section 4bis (ie between current section 4 and current section 5) that:
> 		- discusses the fact that another transport protocol could be defined in the future (although out of scope for this document) that could provide near-real-time exchange of the CDNI Logging records defined in section 3, such as a Tail-based approach. 
> 		- discusses the fact that this would ensure that the same CDNI logging information (ie Records) can be used for both non-real-time and near-real-time applications.

I have edited the documents as discussed above.

The beginning of section 4 now reads:

"
4.  Protocol for Exchange of CDNI Logging File After Full Collection

   This section specifies a protocol for the exchange of CDNI Logging
   Files as specified in Section 3 after the CDNI Logging File is fully
   collected by the dCDN.

   This protocol comprises:

   o  a CDNI Logging feed, allowing the dCDN to notify the uCDN about
      the CDNI Logging Files that can be retrieved by that uCDN from the
      dCDN, as well as all the information necessary for retrieving each
      of these CDNI Logging Files.  The CDNI Logging feed is specified
      in Section 4.1.

   o  a CDNI Logging File pull mechanism, allowing the uCDN to obtain
      from the dCDN a given CDNI Logging File at the uCDN's convenience.
      The CDNI Logging File pull mechanisms is specified in Section 4.2.

   An implementation of the CDNI Logging interface on the dCDN side (the
   entity generating the CDNI Logging file) MUST support the server side
   of the CDNI Logging feed (as specified in Section 4.1) and the server
   side of the CDNI Logging pull mechanism (as specified in
   Section 4.2).

   An implementation of the CDNI Logging interface on the uCDN side (the
   entity consuming the CDNI Logging file) MUST support the client side
   of the CDNI Logging feed (as specified in Section 4.1) and the client
   side of the CDNI Logging pull mechanism (as specified in
   Section 4.2).
“

and I have added a new section:

“
5.  Protocol for Exchange of CDNI Logging File During Collection

   We note that, in addition to the CDNI Logging File exchange proptocol
   specified in Section 4, implementations of the CDNI Logging interface
   MAY also support other mechanisms to exchange CDNI Logging Files, in
   particular mechanisms allowing the exchange of the CDNI Logging File
   to start before the file is fully collected.  This can allow CDNI
   Logging Records to be communicated by the dCDN to the uCDN as they
   are gathered by the dCDN without having to wait until all the CDNI
   Logging Records of the same logging period are collected in the
   corresponding CDNI Logging File (an approach commonly referred to as
   "tailing" of the file).  Such an approach could be used, for example,
   to exchange logging information with a significantly reduced time-lag
   (e.g., sub-minute or sub-second) between when the event occurred in
   the dCDN and when the corresponding CDNI Logging Record is made
   available to the uCDN.  This can satisfy log-consuming applications
   requiring extremely fresh logging information such as near-real-time
   content delivery monitoring.  Such mechanisms are for further study
   and outside the scope of this document.
“

Cheers

Francois