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

[Kevin J Ma <[e-mail]>]

I can make Wed if that is easiest.

> -----Original Message-----
> From: CDNi [mailto:[e-mail]] On Behalf Of Jan Seedorf
> Sent: Friday, February 28, 2014 11:39 AM
> To: [e-mail]
> 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?
>
> 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
>
> > -----Original Message-----
> > From: CDNi [mailto:[e-mail]] On Behalf Of Jan Seedorf
> > Sent: Thursday, February 27, 2014 3:30 PM
> > To: [e-mail]
> > 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):
> >
> > 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:[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
> >
> > _______________________________________________
> > CDNi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cdni
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni