Content Distribution Network Interconnection (CDNI) Problem Statement
RFC 6707

Received changes through RFC Editor sync (changed abstract to 'Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.

The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot comment]
I found Appendix A a little suspect. While it demonstrates that the problem could be solved, it also seems to end-run the discussion of which protocol solution should be developed. I would like it if the introduction indicated that the content of the Appendix is purely examples and that further analysis will be made before the WG decides on the correct solutions.

[Ballot comment]
[Thanks for addressing my DISCUSS and COMMENT, which I kept for the record below, since this draft will be on the next IESG telechat]

DISCUSS:


Preliminary note: between the 3 different chartered items (problem statement, uses cases, and requirement), I'll be specifically checking for the manageability and operational requirements in the requirement document. So hopefully the uses cases document will not only address what the use cases are, but how the operators plan on supporting those use cases.

The only manageability aspect concern I noticed is

  o  CDNI Logging interface: This interface allows the Logging system
      in interconnected CDNs to communicate the relevant activity logs
      in order to allow log consuming applications to operate in a
      multi-CDN environments.  For example, an upstream CDN may collect
      delivery logs from a downstream CDN in order to perform
      consolidated charging of the CSP or for settlement purposes across
      CDNs.  Similarly, an upstream CDN may collect delivery logs from a
      downstream CDN in order to provide consolidated reporting and
      monitoring to the CSP.

The Logging System doesn't mention fault management, which is consistent with the above text.
However, the problem I have is that section 4.3 "CDNI Logging Interface" mentions "events" for the first time.

  The CDNI Logging interface enables details of logs or events to be
  exchanged between interconnected CDNs, where events could be for
  example log records related to the delivery of content (similar to
  the log records recorded in a web server's access log) as well as
  real-time or near-real time events before, during or after content
  delivery and operations and diagnostic messages.

So clearly, the intend here is that you want to cover fault management as well, right?
Please be consistent between the Logging System definition, the CDNI Logging Interface and this section 4.3

COMMENT:

- the terminology order seemed weird initially when I had to search for a specific item. However, while reading through it, the order nicely helps the reader. Thanks.

- the surrogate definition could be improved to express that the device can be caching content.
This is mentioned later on in the draft:

  CDNs allow caching of content closer to the edge of a network so that
  a given item of content can be delivered by a CDN Surrogate (i.e. a
  cache) to multiple User Agents (and their End Users) without
  transiting multiple times through the network core (i.e from the
  content origin to the surrogate).

- In the Appendix B table of content, there is:

  Appendix B.  Additional Material . . . . . . . . . . . . . . . . . 27
    B.1.  Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 27
    B.2.  Related standardization activites  . . . . . . . . . . . . 29
      B.2.1.  IETF CDI Working Group (Concluded) . . . . . . . . . . 30
      B.2.2.  3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30
      B.2.3.  ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 31
      B.2.4.  ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 32
      B.2.5.  CableLabs  . . . . . . . . . . . . . . . . . . . . . . 32
      B.2.6.  ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32
      B.2.7.  ETSI TISPAN  . . . . . . . . . . . . . . . . . . . . . 32
      B.2.8.  ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . 33
      B.2.9.  Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33
      B.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33
      B.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 34
      B.2.12. Summary of existing standardization work . . . . . . . 34
    B.3.  Related Research Projects  . . . . . . . . . . . . . . . . 36
      B.3.1.  IRTF P2P Research Group  . . . . . . . . . . . . . . . 36
      B.3.2.  OCEAN  . . . . . . . . . . . . . . . . . . . . . . . . 36
      B.3.3.  Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 36
    B.4.  Relationship to relevant IETF Working Groups . . . . . . . 37

B.1 is useful: too many times we don't express which problem(s) we don't plan on addressing
Note that there is a little important line in there that is worth stressing: "Element management interfaces"
B.2 will be obsolete in a year from now. Personally I would not include this one. No strong feelings though
B.3 is not interesting, except maybe the IRTF P2P which could go in B.4
B.4 is very important to us.

Conclusion: I would definitively keep B1 and B4, maybe B2, and not B3 (except IRTF)

[Ballot comment]

  As suggested in the Gen-ART Review by Wassim Haddad, please define
  "Quality of Experience".  This phrase is mentioned four times in the
  document.

[Ballot discuss]
Preliminary note: between the 3 different chartered items (problem statement, uses cases, and requirement), I'll be specifically checking for the manageability and operational requirements in the requirement document. So hopefully the uses cases document will not only address what the use cases are, but how the operators plan on supporting those use cases.

The only manageability aspect concern I noticed is

  o  CDNI Logging interface: This interface allows the Logging system
      in interconnected CDNs to communicate the relevant activity logs
      in order to allow log consuming applications to operate in a
      multi-CDN environments.  For example, an upstream CDN may collect
      delivery logs from a downstream CDN in order to perform
      consolidated charging of the CSP or for settlement purposes across
      CDNs.  Similarly, an upstream CDN may collect delivery logs from a
      downstream CDN in order to provide consolidated reporting and
      monitoring to the CSP.

The Logging System doesn't mention fault management, which is consistent with the above text.
However, the problem I have is that section 4.3 "CDNI Logging Interface" mentions "events" for the first time.

  The CDNI Logging interface enables details of logs or events to be
  exchanged between interconnected CDNs, where events could be for
  example log records related to the delivery of content (similar to
  the log records recorded in a web server's access log) as well as
  real-time or near-real time events before, during or after content
  delivery and operations and diagnostic messages.

So clearly, the intend here is that you want to cover fault management as well, right?
Please be consistent between the Logging System definition, the CDNI Logging Interface and this section 4.3

[Ballot comment]
- the terminology order seemed weird initially when I had to search for a specific item. However, while reading through it, the order nicely helps the reader. Thanks.

- the surrogate definition could be improved to express that the device can be caching content.
This is mentioned later on in the draft:

  CDNs allow caching of content closer to the edge of a network so that
  a given item of content can be delivered by a CDN Surrogate (i.e. a
  cache) to multiple User Agents (and their End Users) without
  transiting multiple times through the network core (i.e from the
  content origin to the surrogate).

- In the Appendix B table of content, there is:

  Appendix B.  Additional Material . . . . . . . . . . . . . . . . . 27
    B.1.  Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 27
    B.2.  Related standardization activites  . . . . . . . . . . . . 29
      B.2.1.  IETF CDI Working Group (Concluded) . . . . . . . . . . 30
      B.2.2.  3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30
      B.2.3.  ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 31
      B.2.4.  ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 32
      B.2.5.  CableLabs  . . . . . . . . . . . . . . . . . . . . . . 32
      B.2.6.  ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32
      B.2.7.  ETSI TISPAN  . . . . . . . . . . . . . . . . . . . . . 32
      B.2.8.  ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . 33
      B.2.9.  Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33
      B.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33
      B.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 34
      B.2.12. Summary of existing standardization work . . . . . . . 34
    B.3.  Related Research Projects  . . . . . . . . . . . . . . . . 36
      B.3.1.  IRTF P2P Research Group  . . . . . . . . . . . . . . . 36
      B.3.2.  OCEAN  . . . . . . . . . . . . . . . . . . . . . . . . 36
      B.3.3.  Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 36
    B.4.  Relationship to relevant IETF Working Groups . . . . . . . 37

B.1 is useful: too many times we don't express which problem(s) we don't plan on addressing
Note that there is a little important line in there that is worth stressing: "Element management interfaces"
B.2 will be obsolete in a year from now. Personally I would not include this one. No strong feelings though
B.3 is not interesting, except maybe the IRTF P2P which could go in B.4
B.4 is very important to us.

Conclusion: I would definitively keep B1 and B4, maybe B2, and not B3 (except IRTF)

[Ballot discuss]

There is no mention of privacy in the document. I think there
needs to be. Did the WG discuss that? In particular, I think
you need to say that transiting different legal regimes is
likely to impact on the logging system which may need to
handle anonymisation, obfuscation or removal of some fields.
As a second example, some end users (ok, mostly wearing tin
foil hats for now;-) might also prefer to use a CDN that is more
privacy friendly, so again (mostly) the logging system ought
pay attention to end user privacy, and be able to work while
being privacy friendly.

I think this could be handled via a new "privacy" subsection
of the security considerations section or by adding a bit to
the logging description. I think a short paragraph saying
something like the above would be fine (if that's agreeable)
but I do think its important that this isn't omitted.

Other than that, I think this is a fine document.

[Ballot comment]


- 6.1, "a very private nature" seems wrong, I think you really
mean "sensitive," since data origin authentication will be
needed and isn't really related to confidentiality.  (And
that's why I consider there's no mention of privacy in the
document - just encrypting logs between CDNI nodes doesn't
handle end user privacy.)

[Ballot discuss]
One small thing, easily dealt with:

The definitions of "upstream CDN" and "downstream CDN" are confusing to me.  From Figure 1, they appear to be what I expect: the upstream CDN is the one that's farther from the end user.  But when I read the definition:

   Upstream CDN: For a given End User request, the CDN (within a pair of
   directly interconnected CDNs) that redirects the request to the other
   CDN.

...what I get is that if an EU makes a request to CDN1, and CDN1 redirects that request to CDN2, then CDN1 (the one closer to the user) is the upstream CDN.  Can you clear up this confusion for me?

*** UPDATE, 15 June ***
*** François replies:
The thing is that the CDN that will get the request first (CDN1) is the one that is "closer" to the Content Service Provider, not the one that is "closer" to the enduser.

Effectively both request and content flow in the same direction:
* the initial enduser request is first received by the upstream CDN which is the CDN closer to the Content Service Provider (this is because the upstream CDN is the one who is authoritative for that Content Service Provider and therefore responsible for the whole delivery and the "entry point" into the CDNs).
* the upstream CDN may serve the request itself, or may elect to use CDNI and redirect the request to a CDN that is "closer" to the enduser ie the downstream CDN.
* the enduser will request the content from the downstream CDN, that will acquire it from the upstream CDN, that will acquire it from the Content Service Provider

So, request flows uCDN-->dCDN.
And content flows CSP-->uCDN-->dCDN.

Does that clarify?

*** Barry:
It does, very well; thanks.  If you could put a few words in an appropriate place somewhere early in the document to explain the request and response path like that, I would be happy.  Perhaps it's not needed for the intended audience... but if you can explain it to me in a paragraph or two, then that can go in the document to make it easier for others.

[Ballot comment]
You tell the RFC Editor to remove Appendix B on publication.  But it contains a great deal of useful related information -- why remove it?  Further, the last paragraph of the Introduction refers directly to two parts of Appendix B.

*** UPDATE, 15 June ***
*** François replies:
We discussed this. We also felt there is useful info in the Appendix B but our concerned was that a lot of the information in there was, by definition, mutable (e.g. Non-Goals, relationship to other Working Groups,…).  I think the option we have are:

*A) stick with the plan to remove Appendix B and remove the references to it from the Introduction

*B) retain Appendix B and include a very clear statement at the beginning clarifying that the information in there was true at the time of writing but expected to become stale over time.

We'd like to get yours and IESG's guidance on that.

*** Barry:
I prefer option B, because I think it's useful to have this kind of information in an Informational document like this.  But I don't know what the other ADs think.

[Ballot discuss]
Two small things, easily dealt with:

1. This is probably just my lack of understanding:
The definitions of "upstream CDN" and "downstream CDN" are confusing to me.  From Figure 1, they appear to be what I expect: the upstream CDN is the one that's farther from the end user.  But when I read the definition:

   Upstream CDN: For a given End User request, the CDN (within a pair of
   directly interconnected CDNs) that redirects the request to the other
   CDN.

...what I get is that if an EU makes a request to CDN1, and CDN1 redirects that request to CDN2, then CDN1 (the one closer to the user) is the upstream CDN.  Can you clear up this confusion for me?

2. You tell the RFC Editor to remove Appendix B on publication.  But it contains a great deal of useful related information -- why remove it?  Further, the last paragraph of the Introduction refers directly to two parts of Appendix B.

IANA has reviewed draft-ietf-cdni-problem-statement-06, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Content Distribution Network Interconnection (CDNI) Problem Statement) to Informational RFC


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document:
- 'Content Distribution Network Interconnection (CDNI) Problem Statement'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Content Delivery Networks (CDNs) provide numerous benefits: reduced
  delivery cost for cacheable content, improved quality of experience
  for End Users and increased robustness of delivery.  For these
  reasons they are frequently used for large-scale content delivery.
  As a result, existing CDN Providers are scaling up their
  infrastructure and many Network Service Providers (NSPs) are
  deploying their own CDNs.  It is generally desirable that a given
  content item can be delivered to an End User regardless of that End
  User's location or attachment network.  This is the motivation for
  interconnecting standalone CDNs so they can interoperate as an open
  content delivery infrastructure for the end-to-end delivery of
  content from Content Service Providers (CSPs) to End Users.  However,
  no standards or open specifications currently exist to facilitate
  such CDN interconnection.

  The goal of this document is to outline the problem area of CDN
  interconnection for the IETF CDNI (CDN Interconnection) working
  group.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This draft is intended to become an Informational RFC, and the type is indicated in the title page header.

The document shepherd believes that this is the proper type of RFC for a problem statement document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Content Delivery Networks (CDNs) provide numerous benefits: reduced
delivery cost for cacheable content, improved quality of experience
for End Users and increased robustness of delivery. As a result,
many CDNs have been deployed in the Internet with varying geographic
footprints and capabilities. It is generally desirable that a given
content item can be delivered to an end user regardless of that end
user's location or attachment network. Therefore, many CDN operators
are motivated to interconnect their independent CDNs so they can
interoperate as an open content delivery infrastructure. However,
no standards or open specifications currently exist to facilitate
all aspects of such CDN interconnection.

Working Group Summary

There was strong consensus in the CDNI WG to publish this document
as its Problem Statement.

Document Quality

Despite many existing CDN implementations, there are no
implementations of CDN interconnection that resolve the functional
and operational challenges raised in this Problem Statement.
Many CDN vendors and service providers are interested in adopting
IETF solutions to the problems raised in this document.

Personnel

Richard Woundy (richard_woundy@cable.comcast.com) is the Document Shepherd.
Martin Stiemerling is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd reviewed the document for nits and for content, and believes that this version of the document is ready for publication, with the possible exception of additional review of the Security Considerations section by a security expert.

(4) Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

This draft was extensively reviewed by the CDNI working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The Security Considerations section may need additional expert review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The Document Shepherd has no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that no IPR disclosures will be required to
be filed for full conformance with the provisions of BCP 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

This document represents the strong concurrence of a significant proportion of the CDNI working group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No one has raised an objection against this document, to the best knowledge of the Document Shepherd.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The Document Shepherd has found no nits with the draft.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

As a Problem Statement with Informational content only, no formal review is required.

(13) Have all references within this document been identified as
either normative or informative?

All references within the document have been identified as informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are no normative references.

(15) Are there downward normative references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document has no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries will be created by this document.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No parts of the document are written in a formal language.

(end)