Subject: [CDNi] 1st batch of comments on cdni-framework

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 29 Oct 2012 18:16:11 +0000

Hi Larry, Bruce,

Below is a 1st batch of comments from a review as an Individual (I got till section 3.2).
I'll send more when I continue the review.

HTH

Francois

===========================================================

Abstract section and Introduction section:
OLD:
"
CDN Interconnection requires the specification of several
   interfaces and mechanisms to address issues such as request routing,
   metadata exchange, and the acquisition of content by one CDN from
   another.
"
NEW:
"
CDN Interconnection requires the specification of several
   interfaces and mechanisms to address issues such as request routing,
   distribution metadata exchange, and logging information exchange across CDNs.
"
(Rationale: since this discusses the "specification if several interfaces", these should be aligned to the actual CDNI interfaces).

OLD:
"
(and without
   attempting to take into account how the Downstream CDN may in turn
   redirect the user agent)
"
NEW:
"
(and without
   attempting to take into account how the Downstream CDN may in turn
   redirect the request)
"
(Rationale: the redirection decision can depend on other parameters/attributes than user agent e.g. type of content).

OLD:
"
In fact, this situation effectively exists today in the
   sense that a single CSP can currently connect to more than one CDN.
"
NEW:
"
In fact, this situation effectively exists today in the
   sense that a single CSP can currently delegate its content delivery to more than one CDN.
"

Section 1.2:
"
   o  Control Interface: Operations to discover, initialize, and
      parameterize the other CDNI interfaces, as well as operations to
      pre-position, revalidate, and purge both metadata and content.
      The latter sub-set of operations is sometimes collectively called
      the "trigger interface."
   o  Request Routing Interface: Operations to determine what CDN (and
      optionally what surrogate within a CDN) is to serve end-user's
      requests.  May include a combination of:
      *  Asynchronous operations to exchange routing information (e.g.,
         the network footprint served by a given CDN) that enables CDN
         selection for subsequent user requests; and
      *  Synchronous operations to select a delivery CDN (surrogate) for
         a given user request.
   o  Metadata Interface: Operations to communicate metadata that
      governs the how content is delivered by interconnected CDNs.
      Examples of CDNI metadata include geo-blocking directives,
      availability windows, access control mechanisms, and purge
      directives.  May include a combination of:
      *  Asynchronous operations to exchange metadata that govern
         subsequent user requests for content; and
      *  Synchronous operations that govern behavior for a given user
         request for content.
   o  Logging Interface: Operations that allow interconnected CDNs to
      exchange relevant activity logs.  May include a combination of:
      *  Real-time exchanges, suitable for runtime traffic monitoring;
         and
      *  Off-line exchanges, suitable for analytics and billing.
"
This is an alternative definition to the one included in the Problem Statement. I would suggest that for each interface you first quote (with quotation marks) the text of the corresponding definition from RFC6707 and then indicate (without quotation marks) the additional information you want to provide.
Note in particular that the current terminology for the Asynchronous and Synchronous part of RRI is "CDNI Request Routing Redirection interface" and "CDNI Footprint & Capabilities advertisement interface".

section 1.2:
OLD:
"
There is some ambiguity as to the line between the set of trigger-
   based operations in the Control interface and the Metadata interface.
"
NEW:
"
There is some potential overlap between the set of trigger-
   based operations in the Control interface and the Metadata interface.
"

OLD:
"
via the Metadata interface?
"
NEW:
"
via the Metadata interface.
"

OLD:
"
   The distinction we draw has to do with what the caller knows the
   metadata being applied to content delivery by the callee. 
"
NEW:
"
   The distinction we draw has to do with what the caller knows about the
   metadata being applied to content delivery by the callee. 
"

section 2.1:
OLD:
"
in-protocol redirection mechanisms such as the HTTP 302
   redirection response
"
NEW:
"
in-protocol redirection mechanisms such as the HTTP 302 or 307
   redirection response
"

section 2.1.1:
2nd paragraph. I suggest mentioning a few other limitations of DNS redirection such as inability to take into account the type of request content, the URI path or attributes of the user agent.

OLD:
"
(1) there is a limit to the number of delivery nodes a single DNS server
   can manage
"
NEW:
"
(1) there is a limit to the number of alternate IP addresses a single DNS server
   can manage
"
(Rationale: in a context of multi-CDN, the IP address may not point to delivery nodes"

OLD:
"
to preserve the timeliness of the redirection.
"
NEW:
"
to preserve the freshness of the redirection.
"
(To me "timeliness" refers to the redirection arriving fast enough, which is not the issue here. But feel free to ignore if this is not correct)

section 2.1.2:
OLD:
"
HTTP redirection makes use of the "302" redirection response of the
   HTTP protocol. 
"
NEW:
"
HTTP redirection makes use of the redirection response of the
   HTTP protocol (e.g. "302", "307"). 
"

OLD:
"
The advantages of 302 redirection
"
NEW:
"
The advantages of HTTP redirection
"

section 2.1.2, 1st paragraph:
I suggest mentioning a few additional benefits of HTTP redirection i.e. visibility on other attributes (e.g. URI path, content type, user-agent type,..)

section 3:
OLD:
"
and the latter being the best CDN to deliver content to the end-user.
"
NEW:
"
and the latter being the CDN selected by Operator A to deliver content to the end-user.
"

OLD:
"
The interconnection relationship may be symmetric between these two CDN operators, but
   for simplicity we show the interaction in one direction only.
"
NEW:
"
The interconnection relationship may be symmetric between these two CDN operators, but each direction can be considered as operating independently of the other so 
   for simplicity we show the interaction in one direction only.
"

Figure2:
I recommend that all figures try use the same convention for which side is the uCDN and which is the dCDN. Since RFC6707 model has the uCDN on the left and the dCDN on the rigt, I would recommend that all figures use that convention. It avoids having to swap mental picture from figure to figure.

Figure2:
OLD:
"
[Asynch RRI Push]
"
NEW:
"
[Asynch RRI/Footprint & Cap Push]"
"
(also, you need to introduce the RRI acronym before)

Figure2:
OLD:
"
[Sync RRI Pull]
"
NEW:
"
[Synch RRI/Footprint & Cap Pull]"
"

Figure 2:
everywhere, replace "metadata" by "CDNI metadata"

Figure 2:
I would swap the order between 1 and 2, just cause , if it is to happen, footprint & caps advertisement seems more "pre-requisitite" than content metadata exchange (i.e. kind of even more asynchronous since it is not even related to any content, and may be even need to first decide which dCDN to preposition metadata into).

Figure2:
in the description for each step below the figure, please make sure that for each step you indicate which CDNI interface is exercised.

Figure2:
I suggest replacing the phrase "metadata push" everywhere by something like "CDNI metadata pre-positioning". just cause we are not really "pushing" it, but triggering a pull. 

section 3.1:
"
We use the term "CDN-domain" to refer to the host name (a FQDN) at the beginning of each URL.
"
The text uses "CDN Domain" or "CDN-Domain" or "CDN domain". I suggest you always use the same single form.
Since the term is defined at the beginning of the doc, you can probably avoid to redefine it in section 3.1 (currently with less precise definition).

section 3.2:
"
(It is likely that the agreement would be made in
   both directions, but we focus on just one here for clarity.)
"
this is redundant with earlier text ("The interconnection relationship may be symmetric between these two CDN operators, but each direction can be considered as operating independently of the other so for simplicity we show the interaction in one direction only.") and can be safely removed.

section 3.2:
"
We refer to
   this domain as a "distinguished" CDN domain to convey the fact that
   its use is limited to the interconnection mechanism; such a domain is
   never embedded in URLs that end-users request.
"
This wording is confusing to me because after the uCDN redirect, the CDN Domain is indeed used by the end-user in its URI : "HTTP peer-a.op-b.net/cdn.csp.com ".
I think the point is that a "distinguish CDN domain" is never used as the CDN Domain for a CSP. No?
While talking about the distinguished CDN domain fro redirection I would mention that the granularity of such a CDN domain is flexible (i.e. there could be one for the pair of <uCDN/dCDN>, one per triple uCDN CSP for the pair of <uCDN/dCDN> or anywhere in between (i.e. per set of uCDN CSPs, per type of content across uCDN CSPs).

section 3,2:
"
The operators must also agree on some distinguished CDN-domain that
   will be used for inter-CDN acquisition of CSP's content from uCDN by
   dCDN.  In this example, we'll use op-b-acq.op-a.net.
"
I would replace "must also agree" by "can also agree" because it does not absolutely have to be that way: uCDN may be able to distinguish an acquisition request from a end-user request even if they use the same domain name.
In fact you should use a consistent terminology everywhere in this section insisting on the fact that this is just an example (e.g.. "We assume for this example that" ) and avoid "must".

OLD:
"
via a defined interface.
"
NEW:
"
via a defined CDNI interface.
"