[CDNi] FCI Analysis

["Matt Caulfield (mcaulfie)" <[e-mail]>]

As promised in Vancouver, I have read through the two current FCI proposals (along with some of their normative references) and I have put together the following analysis. 

The text below first reviews the CDNI Requirements for FCI as well as some of the highlights from the FCI Semantics. Next, a short list of (what I feel are) the key points from each draft. Finally, my analysis comparing the drafts based on their approach to FCI (and not the quality or the level of detail in the documents).

If you have not done so already, then I would also  recommend reading Jon Peterson's email from February 6 ("footprint and capabilities mechanisms"). 

=======================================
FCI Requirements (draft-ietf-cdni-requirements)
-------------------------------------------------------------
The CDNI FCI must allow a dCDN to communicate the following to a uCDN:
1) Ability/willingness of dCDN to handle requests from uCDN
2) Information to facilitate selection of a dCDN by uCDN (e.g. capabilities, resources, affinities)
3) Aggregated versions of #1 and #2 in the cascaded CDN case
4) Administrative limits and policies (e.g. max number of requests)
5) Specific capabilities including:
	a) delivery protocol
	b) acquisition protocol
	c) redirection mode (DNS vs HTTP)
	d) logging options
	e) metadata options
6) Delivery authorization mechanisms (e.g. uri signing)

The FCI must also support extensibility and versioning for new capabilities and footprints.

=======================================
FCI Semantics (draft-ietf-cdni-footprint-capabilities-semantics) 
-------------------------------------------------------------
Design Decisions
1) Advertising Limited Coverage - should footprints be binary or rated via qualitative score?
2) Capabilities and Dynamic Data - what capabilities are static vs dynamic? If dynamic, how dynamic?
3) Advertisement vs Queries - synchronous query response model (per end client request) or state replication? 
4) Avoiding / Handling Cheating dCDNs - capabilities should be eventually verifiable by the uCDN

Mandatory footprint types:
1) List of ISO Country Codes
2) List of AS numbers
3) Set of IP-prefixes

FCI must be able to convey the entire footprint/capabilities and optionally dynamic updates.

Footprints and Capabilities are dependent and tied together. Certain capabilities are only available for specific footprints.

Important to note that most footprint information will be agreed upon out of band (e.g. via contracts). FCI can be considered a means for providing changes or updates to that previously agreed upon set of footprints and capabilities.

=======================================
 FCI using ALTO (draft-seedorf-cdni-request-routing-alto-06) 
-------------------------------------------------------------
This proposal is based on the ALTO (Application Layer Traffic Optimization) protocol (draft-ietf-alto-protocol), currently under development by the ALTO working group. ALTO protocol specification is currently an Active Internet-Draft in the "Submitted to IESG for Publication" state. 

Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to determine footprint and capabilities of dCDN.

An ALTO Network Map indicates coverage/reachability to groups of endpoints. Endpoints are grouped into PIDs. All endpoints within a single PID share the same capabilities. 

Each PID is associated with a set of properties. Each property corresponds to a capability. The concept of a PID Property Map is defined by draft-roome-alto-pid-properties (an active Internet-Draft). The same draft defines rules for implicit inheritance of properties for overlapping PIDs (e.g. one PID may correspond to a set of IP prefixes which is a subset of another PID; in this case, properties in the PID Property Map for the bigger set (i.e. shorter IP prefix) also apply to the smaller set (i.e. longer IP prefix)).

Presumably the uCDN is configured with the URI for an ALTO IRD (Information Resource Directory) per dCDN. The IRD in turn provides two URIs. One for accessing the dCDN's Network Map and another for the dCDN's PID Property Map. However, this is not described explicitly.

The draft defines the same basic set of capabilities as defined in the requirements but does not describe their encoding in depth.

The ALTO protocol only registers IPv4 and IPv6 endpoint types. Assuming that this draft would register ISO Country Codes and AS numbers as new endpoint types, but not clear from the text.

ALTO Cost Map could be used to determine the cost of the dCDN delivering to each group of endpoints (PID). 

The PID concept offers a level of indirection between footprints and capabilities allowing them to vary independently.

ALTO also offers filtered querying in order to avoid fetching an entire network map or pid property map. 

Future extensions to ALTO will include asynchronous notifications and incremental updates as described by draft-schwan-alto-incr-updates (currently an Expired Internet-Draft). Expecting progress soon in this area from the ALTO WG.

=======================================
FCI using HTTP and CDNI-specific Representation (draft-ma-cdni-capabilities-04) 
-------------------------------------------------------------
This proposal is based on a CDNI-specific representation of footprints and capabilities. Footprints and capabilities are encoded in JSON and transported via HTTP.

Stated objective is to distill dCDN resource knowledge into simple set of capabilities and their footprints. That is, each capability has an associated footprint.

The draft defines the same basic set of capabilities as defined in the requirements and provides some examples of their encoding.

Each capability has a name, a list of values, and an optional list of footprints. The list of values is specific to the capability name.

The optional footprint list restricts its capability. Each footprint has a type, list of values, and an optional mode. The list of values is specific to the footprint type. A registry is defined for footprint types and includes country code, AS number, and IP prefix.

The footprint mode may be set to "replace", "include", or "exclude" which indicates how the footprint should be treated with respect to "previous" footprint information. In this context, "previous" refers to incremental updates which are sent asynchronously from the dCDN to the uCDN. The "replace" mode indicates that any previous information about the footprint should be discarded and replaced entirely with the new information. The "include" mode indicates an addition to the footprint while "exclude" indications a subtraction.

The draft does not provide a means for conveying footprint cost information.

In practice, the dCDN FCI Server would return a full F&C document in response to HTTP GET requests. An HTTP GET would be used to initialize the state of the uCDN. In response to a GET, all modes are set to "replace".

The proposal also allows the dCDN to send asynchronous HTTP POSTs to uCDN for updating the F&C. Updates may use "include" and "exclude" modes for partial updates. Each update includes a sequence numbers (via an CDNI-FCI-seq HTTP header) in order to detect loss. Lost updates result in a reset and a re-initialization.

=======================================
Analysis
-------------------------------------------------------------

Transport and Encoding: both proposals rely on HTTP transport and JSON encoding. This is a good starting point and is in line with current CDNI WG documents (e.g. triggers and metadata drafts). 

Data Representation: in the case of draft-seedorf, the existing ALTO representations for network and property maps are leveraged. These data structures clearly fit the CDNI use case and have the benefit of prior review. In the case of draft-ma, a new CDNI-specific representation is defined. There is no clear technical deficiency with either approach given that a newly defined representation can be as flexible as needed and the ALTO representation is generic enough to support the CDNI use case. Leveraging an existing protocol has obvious advantages but it is unclear to me whether or not adding a dependency on the ALTO WG will be problematic in any way.

Hierarchy: in the case of draft-seedorf, footprints have capabilities. In the case of draft-ma, capabilities have footprints. In the single CDN case, neither option is deficient. In the cascaded CDN case, the draft-seedorf approach seems more intuitive. Aggregated footprint and capability information is constructed simply by appending the footprints of all dCDNs. 

Cost Information: in the case of draft-seedorf, a loose description is provided of how to apply ALTO Cost Maps to footprints. In the case of draft-ma, no solution is described. Cost information is only useful when multiple dCDNs can claim the same end clients in their footprint advertisements. However, regardless of the use case, business logic is likely to kick in before such cost metrics would be useful. Neither approach includes a definitive proposal in this area.

Extensibility and Versioning: Versioning of the FCI protocol is not discussed by either draft. Extensibility is alluded to and is clearly possible. However, the details are lacking in this area.

Dependence on ALTO WG: In the case of draft-seedorf, a dependency is introduced on the ALTO WG and a few drafts in progress. In the case of draft-ma, no such dependency is required. The benefits of leveraging ALTO include the ability to easily reuse the work that the ALTO WG has done in hardening the error handling, security, encoding, and processing of the ALTO protocol. However, the difficulty of these efforts is not insurmountable and could be reproduced in a CDNI-specific proposal. 

Capability Inheritance: in the case of draft-seedorf, the PID Property Map defines rules for implicit inheritance between multiple overlapping PIDs. In the case of draft-ma, no special inheritance rules exist. These inheritance rules may complicate implementation of FCI. Completely explicit capabilities, such as in draft-ma, may be a better approach.

Update Notifications: in the case of draft-seedorf, no strong story for update notifications is provided. The ALTO Incremental Updates draft is referenced. However, this draft is expired. In the case of draft-ma, an HTTP POST may be sent from dCDN to uCDN which includes the incremental update. Assuming that update notifications is a real requirement, then draft-ma has a more concrete approach in this area. However, a bidirectional HTTP interface breaks the RESTful nature of the interface. 

Incremental Updates: in the case of draft-seedorf, the ALTO Incremental Update draft is referenced. This draft describes the use of JSON Patch for encoding incremental changes to ALTO information. Additionally, ALTO allows for filtered queries which could be used for obtaining partial information. In the case of draft-ma, a scheme including sequence numbers, a new HTTP header, and a "mode" is used for conveying incremental changes via HTTP POST. Like the update notifications, the draft-ma proposal is more concrete in this area. However, again, the ALTO approach is more RESTful. Additionally, adding a new HTTP header for this purpose may not be workable.

Draft Maturity: both draft-seedorf and draft-ma require another level of detail. Neither describe versioning and extensibility. Neither discuss the encoding of logging and metadata capabilities which may pose significant challenges. 

=======================================
Conclusion
-------------------------------------------------------------
All in all, both drafts are well-written and viable candidates as a starting point for our FCI standard. 

I would suggest that the working group must first decide whether the benefits of reusing the ALTO syntax and semantics outweigh the costs or if defining something CDNI-specific is a better option. As far as I can tell, the data representation defined by ALTO meets the needs of CDNI. My only concern is a dependency on the progress of the ALTO WG. Starting with a CDNI-specific representation provides maximum flexibility.

I would also recommend that we first focus on a simple HTTP GET interface and then, once stable, turn our attention to incremental updates.

Cheers,
Matt