Subject: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities"

From: Jan Seedorf <[email-masked]>
Date: Fri, 1 Jun 2012 13:12:46 +0000

Dear all,

Please find attached my notes from the "Footprint / Capabilities" design team virtual meeting we had this week.

 - Jan

Notes CDNI Footprint/Capabilities Call - May 30, 2012
***************************************************
-- introduction from Francois on goals and scope of the call
-- Jon/Stefano: summarize status quo, still quite a few open issues and no definition for footprint yet, lately some more email activity
-- agreement that ISP-owned CDN is a main use case, if not the most important use case; Francois: use-case doc covers multiple scenarios, incl. ISP-CDNs
-- Jon: focusing on ISP-CDN may simplify things a lot, if for each IP-address only one dCDN can serve it; Stefano/Francois: we should not look at only this case; 
-- Francois: solution must be able to support a situation with overlapping footprint, right? Agreement from Stefano, agreement that different dCDN may claim overlapping footprints
-- Francois: business models may have an impact on who makes CDN selection decisions
-- Stefano: why not focus on a single scenario and focus on the mechanism?
-- Enrico: should dCDN advertise where they have the caches or what the bandwidth is? we need to take the incentive away for the dCDN to cheat
-- Jon: there are other choices than prefixes for footprints, e.g. "North America" or cache locations
-- Stefano: we should start with a simple case, so prefixes could be a starting point
-- Allan: location of caches say nothing about the connectivity to endpoints on the Internet
-- Enrico: we need to have the dCDN advertise something the uCDN can verify, otherwise dCDN will cheat
-- Francois: dCDN information should be verifiable, that's a key point to note down
-- Francois: a cheating dCDN may not be the end of the world because there are strong contractual agreements between uCDN and dCDN
-- agreement that we do not consider real-time verification of dCDN statements but afterwards verification of cheating dCDN is fine
-- Francois: let's try to converge - a) upstream CDN makes the decision, b) let's not try to hard to make dCDN information immediately verifiable, c) prefix is probably inevitable as one core footprint definition we could start working with; Jon: agree with this process suggestion
-- Jon: how does a over-the-top CDN derive its footprint?
-- Stefano: would limit the scope, uCDN decision should be made autonomously
-- Jon: we need the semantics of what a footprint is/means
-- Francois: semantic of footprint can be simply willingness to serve
-- Allan: AS-hops is in fact a metric for quality, hard to define via SLA for all users what "good quality" means
-- Jon: also a question where the work gets done, at the dCDN or at the uCDN
-- Francois: footprint means "willingness to serve", we have agreed on that; we also have agreed that the uCDN needs more information, there are several proposals how to do this
-- Jon: need to discuss more on resource advertisement model vs. coverage / willingness to serve model

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 4 Jun 2012 13:38:54 +0200

Hello Jan,

Thanks for extracting the highlights of our discussion. A few minor comments below:

> Notes CDNI Footprint/Capabilities Call - May 30, 2012

Following that, I think there was some discussion and eventually some agreement that there might be more models but there is one model that we are clear we need to make work: model where the decision is made by 
the uCDN (i.e. uCDN selects the dCDN).

> -- Francois: dCDN information should be verifiable, that's a key point to note down

Another related point I tried to make then is that "existence of an incentive to cheat" and "cheat-ability" are more or less common to all "footprint" approaches.

> -- Francois: let's try to converge - a) upstream CDN makes the decision, b) let's not try to hard to make dCDN information immediately verifiable,

s/try to hard/try too hard/

> c) prefix is probably inevitable as one core footprint definition we could start working with; Jon: agree with this process suggestion
> -- Francois: footprint means "willingness to serve", we have agreed on that;

or perhaps more accurately : footprint means "willingness to serve" + "some topology information to help uCDN assess in how good a position the willing CDN actually is to serve well". 

> we also have agreed that the uCDN needs more information,

What I meant here is that the uCDN, to make its dCDN selection, will likely make use of other information than what is provided by the CDNI Footprint & Advertisement interface (e.g. price between uCDN and dCDN, past observation of dCDN quality,…).

Francois

> there are several proposals how to do this
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "GUILLOU, Allan" <[email-masked]>
Date: Mon, 25 Jun 2012 12:16:56 +0000

Hello,

What is the next step of the "Footprint / Capabilities" design team?

---
Allan

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Francois Le Faucheur
> Envoyé : lundi 4 juin 2012 13:39
> À : Jan Seedorf
> Cc : [email-masked]
> Objet : Re: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint
> / Capabilities"
>
> Hello Jan,
>
> > -- Jon/Stefano: summarize status quo, still quite a few open issues and
> no definition for footprint yet, lately some more email activity
> > -- agreement that ISP-owned CDN is a main use case, if not the most
> important use case; Francois: use-case doc covers multiple scenarios,
> incl. ISP-CDNs
> > -- Jon: focusing on ISP-CDN may simplify things a lot, if for each IP-
> address only one dCDN can serve it; Stefano/Francois: we should not look
> at only this case;
> > -- Francois: solution must be able to support a situation with
> overlapping footprint, right? Agreement from Stefano, agreement that
> different dCDN may claim overlapping footprints
> Following that, I think there was some discussion and eventually some
> agreement that there might be more models but there is one model that we
> are clear we need to make work: model where the decision is made by
> > -- Enrico: should dCDN advertise where they have the caches or what the
> bandwidth is? we need to take the incentive away for the dCDN to cheat
> Another related point I tried to make then is that "existence of an
> incentive to cheat" and "cheat-ability" are more or less common to all
> "footprint" approaches.
>
> > -- Francois: a cheating dCDN may not be the end of the world because
> there are strong contractual agreements between uCDN and dCDN
> > -- agreement that we do not consider real-time verification of dCDN
> statements but afterwards verification of cheating dCDN is fine
> > -- Francois: let's try to converge - a) upstream CDN makes the decision,
> b) let's not try to hard to make dCDN information immediately verifiable,
>
> > c) prefix is probably inevitable as one core footprint definition we
> could start working with; Jon: agree with this process suggestion
> > -- Allan: AS-hops is in fact a metric for quality, hard to define via
> SLA for all users what "good quality" means
> or perhaps more accurately : footprint means "willingness to serve" +
> "some topology information to help uCDN assess in how good a position the
> willing CDN actually is to serve well".
>
> What I meant here is that the uCDN, to make its dCDN selection, will
> likely make use of other information than what is provided by the CDNI
> Footprint & Advertisement interface (e.g. price between uCDN and dCDN,
> past observation of dCDN quality,...).
>
> Francois
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 25 Jun 2012 13:52:07 +0000

Allan,
Jon and Stefano indicated that we did not need another "extended design team" meeting before the Vancouver IETF meeting and that the input from the 30th May meeting will be folded into the work of the "regular" Design Team led by them.

Jon, Stefano,
Have you been able to schedule the regular calls for the Design Team? 
Any update on your progress?

Thanks

Francois