Re: [CDNi] Date/time for CDNI FCI meeting at IETF-89

[Jan Seedorf <[e-mail]>]

Hi Daryl,

Thanks for the confirmation, good that you can join. See you on Wednesday,

 - Jan

> -----Original Message-----
> From: Daryl Malas [mailto:[e-mail]]
> Sent: Sunday, March 02, 2014 11:01 PM
> To: Jan Seedorf; Kevin J Ma; [e-mail]
> Subject: Re: [CDNi] Date/time for CDNI FCI meeting at IETF-89
> 
> Jan,
> 
> Sorry, I was on holiday and then traveling this afternoon when I saw your
> email.  My flight gets into London around 10:30am, so I should be able to
> make the meeting.  If not readily apparent and as a note, I will only be
> at the IETF from Wednesday - Friday.
> 
> Thanks,
> 
> Daryl
> 
> On 3/2/14, 7:15 AM, "Jan Seedorf" <[e-mail]> wrote:
> 
> >Thanks, Kevin! Since I have not heard from Daryl, let's go for the
> >Wednesday slot:
> >
> >*** WED, March 5th, 15:30-17:30 ***
> >
> >We will meet at the IETF registration desk.
> >
> >I will try to organize a room by then; otherwise we will have to find one.
> >
> > - Jan
> >
> >> -----Original Message-----
> >> From: Kevin J Ma [mailto:[e-mail]]
> >> Sent: Friday, February 28, 2014 5:52 PM
> >> To: Jan Seedorf; [e-mail]
> >> Subject: RE: CDNI FCI meeting at IETF-89
> >>
> >> 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
> >
> >_______________________________________________
> >CDNi mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/cdni