FW: FCI Analysis
Jan Seedorf <Jan.Seedorf <at> neclab.eu>
2014-02-27 14:35:36 GMT
Just a reminder and FYI: ALTO is currently one of two candidates for the CDNI FCI interface
(draft-seedorf-cdni-request-routing-alto). Matt below provided a good comparison of the ALTO-based
approach that Richard Yang and I am proposing, and the alternative approach which would be a
CDNI-specific JSON-based encoding.
From: CDNi [mailto:cdni-bounces <at> ietf.org] On Behalf Of Matt Caulfield (mcaulfie)
Sent: Saturday, February 22, 2014 9:51 AM
To: cdni <at> ietf.org
Subject: [CDNi] FCI Analysis
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)
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
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.
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.
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.
CDNi mailing list
CDNi <at> ietf.org