Re: [CDNi] CDNI FCI meeting at IETF-89
"Y. Richard Yang" <yry@cs.yale.edu> Fri, 28 February 2014 17:05 UTC
Return-Path: <yang.r.yang@gmail.com>
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 2692D1A026F for <cdni@ietfa.amsl.com>; Fri, 28 Feb 2014 09:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 zsWqorvjA3kq for <cdni@ietfa.amsl.com>; Fri, 28 Feb 2014 09:05:36 -0800 (PST)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 683201A0204 for <cdni@ietf.org>; Fri, 28 Feb 2014 09:05:36 -0800 (PST)
Received: by mail-pb0-f53.google.com with SMTP id rp16so996846pbb.26 for <cdni@ietf.org>; Fri, 28 Feb 2014 09:05:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XPc1Lv1fsOzboyua0F/Rh1OEF1xGNHm2BPDmRMqU8/Q=; b=nKKIPDwaCRq1MdkjJLim4Fus/kbposS1ypmxJx6fvJxi27yDqAvROFJVtC3pahOIOc w29Nrb8OjBC80G/0y4yvnhVwDtY4cM0VZI57VMZQwMxy8k05V++HsdnwvR810FkQoPkA lSw9BtUiEneDZERIzeBHXBKhRSbxZph3nbADWuJdkwYLstmVQR21LNJRLCJPpH6OXxoY 5W73tNe+e7GiTOSePiDh0CMRnLEq/UUlTyN4oUFnBbnImM1WXK96dRyXIY5U1wyd97UC UMIpYEVqSf6/L8UG6iirXCydOoms3Bsu5tAEBwLZ81Cqhl8Njrd0OhUgdFzBjwfeEgwH jd1g==
MIME-Version: 1.0
X-Received: by 10.66.144.200 with SMTP id so8mr4755327pab.15.1393607134512; Fri, 28 Feb 2014 09:05:34 -0800 (PST)
Sender: yang.r.yang@gmail.com
Received: by 10.68.144.168 with HTTP; Fri, 28 Feb 2014 09:05:34 -0800 (PST)
In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6D542AF6AF2@MAILR002.mail.lan>
References: <2779C9F0771F974CAD742BAE6D9904FE63B28309@PALLENE.office.hd> <2779C9F0771F974CAD742BAE6D9904FE63B28B24@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6D542AF6AF2@MAILR002.mail.lan>
Date: Fri, 28 Feb 2014 12:05:34 -0500
X-Google-Sender-Auth: pQrgMseX4XzpQkSX6-e12TPuLow
Message-ID: <CANUuoLrPGzWEm+Qjq6aEur3H4E-5-8w3KdznAE6rCjJKaAOZhw@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
To: Kevin J Ma <kevin.ma@azukisystems.com>
Content-Type: multipart/alternative; boundary="047d7b6d9284358d5904f37a72db"
Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/fTJ8eHg2ioXTUF6KUfPgHju-DUA
Cc: "cdni@ietf.org" <cdni@ietf.org>
Subject: Re: [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: Fri, 28 Feb 2014 17:05:41 -0000
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 <kevin.ma@azukisystems.com>wrote: > I can make Wed if that is easiest. > > > -----Original Message----- > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Jan Seedorf > > Sent: Friday, February 28, 2014 11:39 AM > > To: cdni@ietf.org > > 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:cdni-bounces@ietf.org] On Behalf Of Jan Seedorf > > > Sent: Thursday, February 27, 2014 3:30 PM > > > To: cdni@ietf.org > > > 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: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 mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > -- -- ===================================== | Y. Richard Yang <yry@cs.yale.edu> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
- [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