Re: [CDNi] Date/time for CDNI FCI meeting at IETF-89
Daryl Malas <D.Malas@cablelabs.com> Sun, 02 March 2014 22:01 UTC
Return-Path: <D.Malas@cablelabs.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 82DF01A0B34 for <cdni@ietfa.amsl.com>; Sun, 2 Mar 2014 14:01:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.311
X-Spam-Level:
X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.547] 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 WYmpAzB9ni5K for <cdni@ietfa.amsl.com>; Sun, 2 Mar 2014 14:01:38 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 08DD31A0B28 for <cdni@ietf.org>; Sun, 2 Mar 2014 14:01:37 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s22M1Pj0031232; Sun, 2 Mar 2014 15:01:26 -0700
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Sun, 02 Mar 2014 15:01:25 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Sun, 2 Mar 2014 15:01:25 -0700
From: Daryl Malas <D.Malas@cablelabs.com>
To: Jan Seedorf <Jan.Seedorf@neclab.eu>, Kevin J Ma <kevin.ma@azukisystems.com>, "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: [CDNi] Date/time for CDNI FCI meeting at IETF-89
Thread-Index: AQHPNmL0mMAoEH+JcEKUpNmpCJsuNQ==
Date: Sun, 02 Mar 2014 22:01:24 +0000
Message-ID: <CF3913ED.18477%d.malas@cablelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.5.0.27]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <39F9A06283968A4D9A0951A28A156E79@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/OfzHlqRgpSzmL6gr-QikFTIkJak
Subject: Re: [CDNi] Date/time for 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: Sun, 02 Mar 2014 22:01:41 -0000
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" <Jan.Seedorf@neclab.eu> 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:kevin.ma@azukisystems.com] >> Sent: Friday, February 28, 2014 5:52 PM >> To: Jan Seedorf; cdni@ietf.org >> Subject: RE: CDNI FCI meeting at IETF-89 >> >> 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
- Re: [CDNi] Date/time for CDNI FCI meeting at IETF… Daryl Malas
- [CDNi] Date/time for CDNI FCI meeting at IETF-89 Jan Seedorf
- Re: [CDNi] Date/time for CDNI FCI meeting at IETF… Jan Seedorf