Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-04.txt

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 18 Jul 2013 15:12:13 -0400

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-masked]> 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-masked] [mailto:[email-masked]]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>