Hi Jan, A very good document. Here are come comments:
Section 4. This is a key technical section. I feel that the description style is slightly informal. Such a style may be intended, for now. When/if it is time to go formal, I would recommend that it starts with a precise spec of the IRD that a dCDN should announce: a list of required and optional Network Maps, a list of required and optional Cost Maps, Endhost lookup capabilities (e.g., to map from an end user IP address to if it can be served, the delivery protocol, ...). This can give the reader a top-down overview. Section 4.1/4.2: Footprint/Capability Advertisement using Network Map These are very interesting/useful sections. I feel that it can be helpful to go some more in details, i.e., specifies the exact Network Maps that a dCDN should be provided. Here is a list that I tried to extract from your doc and some of our projects: - DeliveryProtocolMap, which specifies, for each delivery protocol name (e.g., https, rmtp, Adobe10.1), as a pid, to the set of end users that the protocol can be delivered; This is from your current spec. Here, you may need to derive a new type, from PIDName as the type of DeliveryProtocol PIDs, to add some syntax checking, for the hash map defined in the current ALTO protocol. - ChargingRegionMap, which specifies, from each charging region (e.g., EU, US, Pacific), as a pid, to the set of end users. This is from a need from our SIGCOMM'12 content multihoming optimization paper ( http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p371.pdf); for example, for Amazon CloudFront, we could not read the contract agreement to figure out which region will serve a given user, and it will be ideal if the CDN (CloudFront) could have provided it. Some technical details/semantics issues that you may then encounter include: T1. Should the union of all end user addresses appear in one map equal to that of another map? For example, the union of all addresses in the DeliveryProtocolMap may contain fewer IP addresses than that in ChargingRegionMap. What does it mean? T2. One value that you motivated about the FCI interface is to provide dynamic information. For this purpose, I feel that it is important to quickly finish the incremental update/subscription interface of ALTO. T3. Do you need to introduce "intermediate" variables to reduce redundancy in your design. For example, DeliveryProtocolMap and ChargingRegionMap may both list a large number of addresses from the same region. Is it important to introduce such "intermediate" variables as shorthands. The ongoing discussion of multiple topology references in ALTO can be quite helpful. In particular, I feel that it can increase modularity to define a slightly fine-grained network map (say a few hundred cities or regions), which can be used by other network maps, as well as the cost maps. One may call this map an AtomMap, to denote that they provide building blocks (units) for other maps to compose on, but each atom can still be much larger than single IP addresses/prefixes. Such atoms can be the unit of updates to reduce update load as well. Section 4.3: Conveying additional information with ALTO Cost Maps I agree that the Cost Maps can provide finer grained information. The current draft defines only n-to-1 or 1-to-n cost matrices. One possibility that n-k cases may arise is that the dCDN provides multiple classes, i.e., each one of the k denote a logical cluster of a given class of surrogate dCDN servers. Do you need a section on how to leverage the endhost property lookup service? This can be a simple way to allow a uCDN to ask a dCDN is a given endhost can be served.... Just some initial comments. Thanks. Richard On Tue, Jul 16, 2013 at 4:41 AM, Jan Seedorf <[email protected]> wrote: > Hi all, > > I have submitted a revision of the draft that outlines how ALTO can be a > solution protocol for the CDNI FCI. The latest version has been changed > quite a bit; it re-visits the latest conclusions in the FCI design team, > and describes how ALTO could be used to advertise the types of footprint > and capabilities that are considered as mandatory by the design team. > > - Jan > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Monday, July 15, 2013 5:26 PM > To: Jan Seedorf > Subject: New Version Notification for > draft-seedorf-cdni-request-routing-alto-04.txt > > > A new version of I-D, draft-seedorf-cdni-request-routing-alto-04.txt > has been successfully submitted by Jan Seedorf and posted to the > IETF repository. > > Filename: draft-seedorf-cdni-request-routing-alto > Revision: 04 > Title: CDNI Request Routing with ALTO > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-seedorf-cdni-request-routing-alto-04.txt > Status: > http://datatracker.ietf.org/doc/draft-seedorf-cdni-request-routing-alto > Htmlized: > http://tools.ietf.org/html/draft-seedorf-cdni-request-routing-alto-04 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-seedorf-cdni-request-routing-alto-04 > > Abstract: > Network Service Providers (NSPs) are currently considering to deploy > Content Delivery Networks (CDNs) within their networks. As a > consequence of this development, there is a need for interconnecting > these local CDNs. The necessary interfaces for inter-connecting CDNs > are currently being defined in the Content Delivery Networks > Interconnection (CDNI) WG. This document focuses on the CDNI > Footprint & Capabilities Advertisement interface (FCI). > Specifically, this document outlines how the solutions currently > being defined in the Application Layer Traffic Optimization (ALTO) WG > can facilitate Footprint & Capabilities Advertisement in a CDNI > context, i.e. how the CDNI FCI can be realised with the ALTO > protocol. Concrete examples of how ALTO can be integrated within > CDNI request routing and in particular in the process of selecting a > downstream CDN are given. The examples in this document are based on > the use cases and examples currently being discussed in the CDNI WG. > > > > > The IETF Secretariat > > _______________________________________________ > CDNi mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cdni >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
