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

From: Jan Seedorf <[email-masked]>
Date: Tue, 16 Jul 2013 08:41:24 +0000

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

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 30 Jul 2013 08:10:27 -0400

Hi Jan,

  I read through the updated draft and had a couple questions:

section 4.2: "where each PID name has a certain 'capability' semantic."
             Does each capability need its own PID?  or can capabilities
             be grouped if they currently have the same footprint, and
             then later ungrouped if a given capability's footprint changes?

section 5: "dowmstream" -> "downstream"

           In figure 2 of the framework document there is an
           "[Async FCI Push]".  Without the Web Socket extension,
           would an ALTO-based FCI required the uCDN to poll the dCDN?
           I think we would want asynchronous push from dCDN to uCDN,
           or at least a triggered pull?

           wrt content and resource availability, are there existing
           extensions (not cited), or are those just future thoughts?

section 6: the cited section 8.2.2 of the alto draft does not discuss
           authentication signatures.  There is no section 8.2.2.  I
           did see section 14 discusses HTTP digest auth over TLS?

           and section 3.2 states that:
           "Additional protocol mechanisms (e.g., expiration times and digital
            signatures for returned ALTO information) are left for future
            investigation."

thanx.

--  Kevin J. Ma

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jan Seedorf
> Sent: Tuesday, July 16, 2013 4:41 AM
> To: [email-masked]
> Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni-
> request-routing-alto-04.txt
> 
> 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
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 30 Jul 2013 18:10:49 -0400

Hi Kevin,

Not in a position to answer the questions for Jan. But some of your
questions are quite interesting to me, and hence the reply.

>              then later ungrouped if a given capability's footprint
I have not seen Jan's detailed encoding yet. If I read your question
correctly, you are looking into the coding efficiency problem, which is
excellent thinking ahead. I see the following encoding approaches:

1. Simple: each PID denotes one and only one capability:

"http" : {  "ipv4" : [
             "0.0.0.0/0",
            ],
            "ipv6":[
             "::/0"
            ]
 },
 "https" : {

   ...
 },
 "rmtp" :  {

   ...

 }

2. Slight more complex: each PID can denote a subset of capabilities (and
even disabilities). A straightforward approach is to build a binary
decision tree, with left support and right not. Each PID denotes a node in
the decision tree:

"http" : { // set of IP addresses },
"!http+https" : { // }

3. Even more complex: introduce coupled network maps, such as
country/locode (http://www.unece.org/cefact/locode/service/location.html),
and then express capabilities on top of these PIDs:

network map 1:

"us/ne" :  { // IP prefixes }
"de" : { // IP prefixes }

network map 2, which uses network map 1:
Using either 1 or 2 above, but based on network map 1, i.e., using PIDs
defined in network map 1 as "atoms":

"http" : {"us/ne", "de"},
"https" : {"de"}

I am sure others can propose additional schemes. Which scheme is more
efficient will depend on the correlation patterns. Assume K capabilities.
Consider a given d-CDN that will have M IP prefixes to announce. What one
may look into is the correlation patterns (clustering, in particular) of
the K* P items and then decide the most effective "compression", both for
typical cases and for updates (delete/addition). I do not see fundamental
issues in expressing them using network maps but as you pointed out, the
right schema, based on app knowledge on correlation, can lead to better
compressions than using generic compression algorithms.

>            extensions (not cited), or are those just future thoughts?
There are proposals on incremental updates and push in ALTO. It is an item
that the WG will fix the details quickly.

>            did see section 14 discusses HTTP digest auth over TLS?
Sorry, the ALTO protocol is going through some major restructures lately.
We are targeting a mid-August date as the date to finalize the base
protocol.

Thanks!

Richard