[CDNi] CDNI FCI meeting at IETF-89
Jan Seedorf <Jan.Seedorf@neclab.eu> Thu, 27 February 2014 14:30 UTC
Return-Path: <Jan.Seedorf@neclab.eu>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11DB1A02CB for <cdni@ietfa.amsl.com>; Thu, 27 Feb 2014 06:30:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level:
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgXapECWNdDU for <cdni@ietfa.amsl.com>; Thu, 27 Feb 2014 06:30:29 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 510941A02E0 for <cdni@ietf.org>; Thu, 27 Feb 2014 06:30:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8BBAC106E8B; Thu, 27 Feb 2014 15:30:27 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE2FPYiXkLgA; Thu, 27 Feb 2014 15:30:27 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 6C1BC106E86; Thu, 27 Feb 2014 15:30:12 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 27 Feb 2014 15:29:51 +0100
From: Jan Seedorf <Jan.Seedorf@neclab.eu>
To: "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: CDNI FCI meeting at IETF-89
Thread-Index: Ac8zyF3Yu5l8TaDNRtCX/eqLbyHWsA==
Date: Thu, 27 Feb 2014 14:29:51 +0000
Message-ID: <2779C9F0771F974CAD742BAE6D9904FE63B28309@PALLENE.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.5.89]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/uGHIjfONsbk5kkM37Ha5pw-S2Sg
Subject: [CDNi] CDNI FCI meeting at IETF-89
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 14:30:33 -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:cdni-bounces@ietf.org] On Behalf Of Matt Caulfield > (mcaulfie) > Sent: Saturday, February 22, 2014 9:51 AM > To: cdni@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) > ------------------------------------------------------------- > 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 > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni
- [CDNi] CDNI FCI meeting at IETF-89 Jan Seedorf
- Re: [CDNi] CDNI FCI meeting at IETF-89 Jan Seedorf
- Re: [CDNi] CDNI FCI meeting at IETF-89 Kevin J Ma
- Re: [CDNi] CDNI FCI meeting at IETF-89 Y. Richard Yang