Subject: [CDNi] New version of the CDNI Logging draft posted

From: <[email-masked]>
Date: Mon, 22 Oct 2012 19:06:17 +0000

Folks,

We have submitted a new version of the CDNI logging draft:
URL:             http://www.ietf.org/internet-drafts/draft-bertrand-cdni-logging-02.txt 
Status:          http://datatracker.ietf.org/doc/draft-bertrand-cdni-logging 
Htmlized:        http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 
Diff:            http://www.ietf.org/rfcdiff?url2=draft-bertrand-cdni-logging-02 

Best regards,

Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 22 octobre 2012 20:59
À : [email-masked]
Objet : I-D Action: draft-bertrand-cdni-logging-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : CDNI Logging Interface
	Author(s)       : Gilles Bertrand
                          Stephan Emile
                          Roy Peterkofsky
                          Francois Le Faucheur
                          Pawel Grochocki
	Filename        : draft-bertrand-cdni-logging-02.txt
	Pages           : 43
	Date            : 2012-10-22

Abstract:
   This memo specifies the Logging interface between a downstream CDN
   (dCDN) and an upstream CDN (uCDN) that are interconnected as per the
   CDN Interconnection (CDNI) framework.  First, it describes a
   reference model for CDNI logging.  Then, it specifies the actual
   protocol for CDNI logging information exchange covering the
   information elements as well as the transport of those.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bertrand-cdni-logging-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-bertrand-cdni-logging-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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.

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 22 Oct 2012 17:17:17 -0400

Hi,

I took a quick look at this document.
I have a few comments.

1) While appendix C is yet to be written, the placeholders seem to already
poo-poo the candidates that are existing IETF standards, without documenting
why they are not viable choices.

2) Appendix C2 references RFC6707, which states some conclusions that have
no documentation as to how the conclusions were reached.
What are the scalability requirements for the CDNI logging interface? 
RFC6707 states that there are "scalability concerns", but doesn't specify
the requirements or the specific concerns. 
There may be valid scalability concerns, but this deserves better
documentation than mere handwaving.
Which scalability requirements are not possible to meet with SNMPv3?

3) RFC6707 states SNMP does not support guaranteed delivery of traps. 
I am not sure how this conclusion was reached.
SNMPv3 has Informs (acknowledged traps), which support application-level
acknowledgement of receipt. 
An SNMPv3 agent could continue to periodically send the Inform until it
receives acknowledgement of receipt.
This would seem to mitigate the concern that use of SNMP "could result in
log records being lost". 
Note that SNMPv1 has been declared Historic, so shouldn't even be considered
a candidate protocol for new usage. 
Only version 3 of SNMP is recommended.

That said, I would think that syslog [RFC5424] might be a better choice for
CDNI logging.
It uses secure, reliable transport over TLS (RFC5425).
Signed syslog messages [RFC5848] can be used by receivers to verify they
have received all the messages sent to them.
If messages are out-of-order or missing, the receiver can determine which
records are missing and request they be resent.
In addition, the signing can be applied to stored logs to verify they have
not been modified from the original message stream.

If you are considering the RECOMMENDED versions of these candidate
protocols, they might better meet the requirements.
But the main point is that the consideration process should be documented
more clearly than this document (or RFC6707) does.

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, October 22, 2012 2:59 PM
To: [email-masked]
Subject: I-D Action: draft-bertrand-cdni-logging-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 25 Oct 2012 19:06:39 +0100

David,

I haven't read the draft but wanted to make a quick comment on scalability.

> What are the scalability requirements for the CDNI logging interface? 

I guess we still need to work on that but I have some models that can predict log volumes given various scenarios and I could probably also pull together some anonymised data from real deployments (if I can get permission from a customer) that we could use to inform any scalability numbers we come up with but that will take a little time to pull together.

But as an example, let's assume a cache is delivering Live MS Smoothstreaming and the clients are requesting the manifest every 10 seconds then a CDN will be generating 1100 log lines a second for each Gbps of traffic it is delivering.

Scale that up to what deployed CDNs are actually delivering and the numbers get pretty big both in terms of log lines/second and data transferred per log.

Of course we need to temper that with the fact that we may want to exchange log lines in batches rather than individually and that not every delivery is going to come from an interconnect and that delivery protocol, HTTP adaptive segment size, average viewing time, etc have a large impact on the number of log lines produced for a given content delivery. In terms of data transfer the main contributor to that is the verbosity of the log line (i.e. how many fields are logged and specifically which fields are logged) as some fields (such as cookies or user agent strings) are significantly more verbose than others (such as port numbers).

Ben