Subject: [CDNi] CDNI FCI meeting at IETF-89

From: Jan Seedorf <[email-masked]>
Date: Thu, 27 Feb 2014 14:29:51 +0000

Dear all,

I took the liberty of setting up a doodle to have some discussions on how to continue with the two current FCI proposals during the IETF-89 week (the chairs allocated some time in the official CDNI slot on THU, but I am afraid it will not be enough if we want to make some progress):

http://www.doodle.com/xfn59dgm5nit9v4a#table

I also took the liberty of inviting the ALTO chairs (in cc), as they can hopefully enlighten us on the ALTO WG timeframe and re-chartering, as dependency on the progress of the ALTO WG has repeatedly been mentioned as being a drawback of an ALTO-based approach.

Please all fill in the doodle if you would like to participate in this meeting at IETF-89.

 - Jan

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

---

From: Jan Seedorf <[email-masked]>
Date: Fri, 28 Feb 2014 16:38:40 +0000

Thanks to all who filled in the doodle so far, it seems that TUE 13:00-15:00 is the best slot; however, Daryl cannot make that one. Any chance you can make a slot before WED afternoon, Daryl?

The 2nd best slot is WED 15:30-17:30, but Kevin cannot make that one. Kevin?

Darly, Kevin, any chance that you guys can in fact make the respective slot above?

 - Jan

> From: CDNi [mailto:[email-masked]] On Behalf Of Jan Seedorf
> Sent: Thursday, February 27, 2014 3:30 PM
> To: [email-masked]
> Subject: [CDNi] CDNI FCI meeting at IETF-89
> 
> Dear all,
> 
> I took the liberty of setting up a doodle to have some discussions on how to
> continue with the two current FCI proposals during the IETF-89 week (the
> chairs allocated some time in the official CDNI slot on THU, but I am afraid it
> will not be enough if we want to make some progress):
> 
> I also took the liberty of inviting the ALTO chairs (in cc), as they can hopefully
> enlighten us on the ALTO WG timeframe and re-chartering, as dependency
> on the progress of the ALTO WG has repeatedly been mentioned as being a
> drawback of an ALTO-based approach.
>

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 28 Feb 2014 11:51:42 -0500

I can make Wed if that is easiest.

> Sent: Friday, February 28, 2014 11:39 AM
> To: [email-masked]
> Subject: Re: [CDNi] CDNI FCI meeting at IETF-89
>
> Thanks to all who filled in the doodle so far, it seems that TUE 13:00-
> 15:00 is the best slot; however, Daryl cannot make that one. Any chance
> you can make a slot before WED afternoon, Daryl?
>
> > Please all fill in the doodle if you would like to participate in this
> meeting at
> > IETF-89.
> >
> >  - Jan
> >
> > > (along with some of their normative references) and I have put
> together
> > the
> > > following analysis.
> > >
> > > of the highlights from the FCI Semantics. Next, a short list of (what
> I feel
> > are)
> > > Important to note that most footprint information will be agreed upon
> out
> > of
> > > protocol (draft-ietf-alto-protocol), currently under development by
> the
> > ALTO
> > > endpoints. Endpoints are grouped into PIDs. All endpoints within a
> single
> > PID
> > > Each PID is associated with a set of properties. Each property
> corresponds
> > to
> > > The optional footprint list restricts its capability. Each footprint
> has a type,
> > list
> > > modes for partial updates. Each update includes a sequence numbers
> (via
> > an
> > > In the case of draft-ma, a new CDNI-specific representation is
> defined.
> > There
> > > case of draft-ma, capabilities have footprints. In the single CDN
> case,
> > neither
> > > by either draft. Extensibility is alluded to and is clearly possible.
> However,
> > the
> > > Update Notifications: in the case of draft-seedorf, no strong story
> for
> > update
> > > However, this draft is expired. In the case of draft-ma, an HTTP POST
> may
> > be
> > > All in all, both drafts are well-written and viable candidates as a
> starting
> > point
> > > for our FCI standard.
> > >

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 28 Feb 2014 12:05:34 -0500

Hi all,

Is there any way that one can participate remotely, say by Skype?

Thanks.
Richard

On Fri, Feb 28, 2014 at 11:51 AM, Kevin J Ma <[email-masked]>wrote:

> > > I also took the liberty of inviting the ALTO chairs (in cc), as they
> can
> > hopefully
> > > > 1) Advertising Limited Coverage - should footprints be binary or
> rated
> > via
> > > > qualitative score?
> > > > alto-pid-properties (an active Internet-Draft). The same draft
> defines
> > rules
> > > > (currently an Expired Internet-Draft). Expecting progress soon in
> this
> > area
> > > > from the ALTO WG.
> > > >
> > > > This proposal is based on a CDNI-specific representation of
> footprints
> > and
> > > > Stated objective is to distill dCDN resource knowledge into simple
> set
> > of
> > > > of values, and an optional mode. The list of values is specific to
> the
> > > footprint
> > > > response to HTTP GET requests. An HTTP GET would be used to
> initialize
> > > the
> > > > CDNI-FCI-seq HTTP header) in order to detect loss. Lost updates
> result
> > in a
> > > > structures clearly fit the CDNI use case and have the benefit of
> prior
> > > review.
> > > > Hierarchy: in the case of draft-seedorf, footprints have
> capabilities.
> > In the
> > > > 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
> > > > regardless of the use case, business logic is likely to kick in
> before
> > such cost
> > > > introduced on the ALTO WG and a few drafts in progress. In the case
> of
> > > draft-
> > > > Capability Inheritance: in the case of draft-seedorf, the PID
> Property
> > Map
> > > > Update draft is referenced. This draft describes the use of JSON
> Patch
> > for
> > > > detail. Neither describe versioning and extensibility. Neither
> discuss
> > the

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================