Subject: [CDNi] Rough Agenda for today's "CDNI Footprint/Capabilties Design Team Call"

From: Jan Seedorf <[email-masked]>
Date: Tue, 9 Oct 2012 13:48:50 +0000

Hi all,

As rough thread for today's call, I suggest the following:
-- short recap of the Vancouver discussions (Jan)
-- continue discussions on capabilities
-- discuss suggestion from Francois on focusing on some key use cases

 - Jan

> -----Original Message-----
> From: Jan Seedorf
> Sent: Tuesday, October 02, 2012 10:49 AM
> To: Jan Seedorf; [email-masked]
> Cc: [email-masked]
> Subject: RE: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Design
> Team Call"
> 
> Based on the doodle, I suggest having design team phone calls on the
> following dates (let's schedule two calls for now and then see where to go
> from there...):
> 
> ** Tuesday, Oct. 9th, 16:00-18:00 CET **
> ** Tuesday, Oct. 16th, 16:00-18:00 CET **
> 
> On these dates most people seem to be able to join. Can someone please
> set up a WebEx meeting for those dates and times?
> 
>  - Jan
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:cdni-footprint-
> > [email-masked]] On Behalf Of Jan Seedorf
> > Sent: Friday, September 28, 2012 2:42 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Design
> Team
> > Call"
> >
> > Hi all,
> >
> > I created a doodle for a CDNI Footprint/Capabilties Design Team Call:
> >
> > http://www.doodle.com/3u7pkrfctqa6u33g
> >
> > I would be good if we could make two calls in October to make progress
> > before the Atlanta meeting, so please fill in the doodle if you are interested
> > in joining the discussion.
> >
> >  - Jan
> > _______________________________________________
> > cdni-footprint mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cdni-footprint

---

From: Vinayak Hegde <[email-masked]>
Date: Tue, 9 Oct 2012 19:38:20 +0530

> -- discuss suggestion from Francois on focusing on some key use cases

Hi Jan,

Can you resend the webex link to the list ? I am unable to find it.

Regards
Vinayak

---

From: Scott Wainner <[email-masked]>
Date: Wed, 10 Oct 2012 05:52:53 -0400

Jan & Team, (resent with edits and CC to cdni)

     I propose two base use cases that may be foundational building 
blocks for more sophisticated use cases:

Definition:
- regional coverage: The CDN has cache nodes that service a well-defined 
geographic or topologically bounded network

- global coverage: The CDN has cache nodes that service any geographic 
region and is topologically unbounded

1) uCDN with regional coverage delegates to one or more dCDN for global 
coverage

Motivations for uCDN to delegate to dCDN might include the following:
     - DECISION:    uCDN client is outside the region
       IMPACT:      uCDN client is better served by global dCDN
       CRITERIA:    uCDN ascertains if the client is outside a 
well-defined region or IP topology
       CRITERIA:    uCDN ascertains if the requested content can be 
delivered by dCDN(s) (short list created)
       CRITERIA:    uCDN determines which dCDN is appropriate (chosen by 
priority)
In this use case, I think its quite simple for the uCDN to know the BGP 
AS or geography covered because the uCDN is under the same 
administrative authority as the IP network to which it is attached.  The 
well-defined region is much more easily bounded. The global dCDN becomes 
a CDN of last-resort.  Let's assume for the moment that the global dCDN 
does NOT provide transitive delegation to other dCDN.  The uCDN decision 
is simple:
   IF (client is in my network AND my region)
   THEN (service client from my uCDN)
   ELSE (consider serving client from global dCDN)
Now you can start adding optional conditions to either service the 
client from either choice such as Time-of-Day, Priority, Cost, etc.

2) uCDN with global coverage delegates to one or more dCDN for regional 
coverage

Motivations for uCDN to delegate to dCDN might include the following:
     - DECISION:    uCDN client is inside a dCDN's well-defined region 
or IP topology
       IMPACT:      uCDN client is better served by regional dCDN
       CRITERIA:    uCDN ascertains if the client is inside a 
well-defined region or IP topology
       CRITERIA:    uCDN ascertains which dCDN's associated with the 
region can deliver the requested content (short list)
       CRITERIA:    uCDN determines which dCDN is appropriate (chosen by 
priority)
In this case, the uCDN needs to know the candidate regions and have the 
ability to associate a client to the candidate region. That means each 
dCDN needs to advertise its candidate region to the global uCDN.  The 
regional dCDN become may be preferred provided the dCDN is available and 
capable of delivering the content.  We have a fairly simple decision 
process:
   IF (client is in region X)
	AND (ISP 1 services region X)
	AND (client is attached to ISP 1's AS)
   THEN (service the client from dCDN of ISP 1)
   ELSE (consider serving client from global uCDN)
Now you can start adding optional conditions to either service the 
client from either choice such as Time-of-Day, Priority, Cost, etc.

N) The intermediate CDN delegates to one or more regional dCDN for 
regional coverage.  The intermediate CDN is also a delegate of a 
regional uCDN.

I don't see that the motivations change from the two cases previously 
defined.  The uCDN delegates to the intermediate CDN to get better 
coverage and the intermediate CDN delegates to the regional dCDN's to 
get better performance.  What is different is the transitive nature of 
the coverage where a regional dCDN advertises its regional footprint 
(region and associated AS) to the intermediate CDN.  The intermediate 
CDN now aggregates all its delegates (regions and associated AS's) and 
advertises that to the uCDN.  For a well connected intermediate CDN, 
that could be a lot of information to flood to the regional uCDN.  If 
the intermediate CDN doesn't have robust coverage, then perhaps it is 
really a regional CDN which means the information in the footprint 
advertisement is sparse.  The decision is simply to indicate which 
regions associated with which AS are transitive in nature.

Summary

I see three mandatory requirements:

1) COVERAGE:
   - AS to which the dCDN is attached
     AND
   - regions to which that dCDN services
2) CAPABILITY:
   - content delivery method
   - authentication method
3) AVAILABILITY:
   - active / operational for servicing requests

On 10/9/12 9:48 AM, Jan Seedorf wrote:
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
> .
>

---

From: Jan Seedorf <[email-masked]>
Date: Fri, 12 Oct 2012 15:31:01 +0000

Dear Scott,

Thanks for sending these use cases. I will in another email send the use cases that Francois had originally suggested (just as input to this discussion).

Anne and Emil: can you please also describe in a mail to this list the use cases you had sketched in the phone call this week?

Then - as discussed - we can hopefully carve out 2-3 use cases we agree on and start the discussion on what capabilities are mandatory for these agreed use cases.

 - Jan

> From: Scott Wainner [mailto:[email-masked]]
> Sent: Wednesday, October 10, 2012 11:53 AM
> Subject: Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'
> 
>