Re: [CDNi] FCI Analysis

[Jan Seedorf <[e-mail]>]

Hi Matt,

Thanks for your detailed analysis and summary below. Regarding the ALTO proposal (draft-seedorf-cdni-request-routing-alto), I can confirm that each time you state "presumably" or similar below (where the draft is not 100% clear and you assume something), your assumptions are correct regarding the ALTO draft. Thanks for the nice to-do list for the next revision, telling us where we need to be more precise and also match the requirements.

I also agree with your conclusion (I stated this before on this list): ALTO is mature (error handling, security, encoding) and RESTful, but at the same time may bring some baggage plus dependency on the ALTO WG.

> I would also recommend that we first focus on a simple HTTP GET interface
> and then, once stable, turn our attention to incremental updates.
Actually, I have wanted to comment on this issue for some time now in a similar fashion: For me, incremental updates are useful for CDNI FCI, but not a must-have for the initial CDNI specifications. After all, everything would work without incremental updates, it is just an optimization to avoid high traffic volumes for ALTO. And compared to e.g. ALTO for P2P, there will only be a few dCDNs per uCDN (certainly not in the range of 10.000s), and it is also not clear that footprint/capability information will change on a high frequency. Do not get me wrong, incremental updates are very useful for CDNI FCI, just in my view not a must-have for the initial specification. Thus I am not worried about this dependency on the ALTO WG. Btw, draft-schwan-alto-incr-updates (the document on ALTO incremental updates) has only expired because the ALTO WG decided to focus on finalizing the core ALTO specification first, before turning its attention on enhancements. Right now, the ALTO WG is re-chartering and incremental updates are on top of the list; and in my view draft-schwan-alto-incr-updates is quite mature and will make progress now.

Again, Matt: thanks for your efforts!

 - Jan

> -----Original Message-----
> From: CDNi [mailto:[e-mail]] On Behalf Of Matt Caulfield
> (mcaulfie)
> Sent: Saturday, February 22, 2014 9:51 AM
> To: [e-mail]
> 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)
> -------------------------------------------------------------
> 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
> 
> 
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni