Subject: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84

From: Jan Seedorf <[email-masked]>
Date: Thu, 2 Aug 2012 17:55:33 +0000

Dear all,

Here are my notes from yesterday's second footprint/capabilities design team side meeting. The same disclaimer applies ("...probably have not captured everything and admittedly the notes are rough in some cases"). Thanks to everyone for taking the time and the (in my view) productive discussion.

 - Jan

-- CDNI Footprint Design team side meeting IETF-84
-- Wednesday, August 1st, 15:00-17:00
**************
-- start discussion by talking about capabilities first
-- Jon: capabilities may only be valid for a partial footprint each
-- Kevin: let's start with global capabilities first, and look later on capabilities that are only valid for a partial footprint
-- Yannick: two different types of capabilities, related to request (e.g. protocol), related to CDN 
-- not clear what these two capabilities classes are, Yannick trying to explain
-- Yannick: classes of requests is first type of capability
-- Kevin: on-net off-net is not a capability
-- Gilles: capabilities are a functionality that I need to rely on
-- Rich: when part of your CDN gets upgraded, you do not want to set up a new contract
-- Jan: do we all agree that there is kind of a generically valid contract, and the interface we are taking about is for giving additional update information with respect to such a contract?
-- Jon: what things do we know that they are useful?
-- Yannick: footprint and capabilities are tied together, does not make sense to announce a capability, if you do not say along for which footprint it is valid
-- agreement on problem we are trying to solve --> provide additional update information about capabilities that have changed/been added since the contract
-- agreement that footprint and capabilities are tied together --> given capabilities may apply only to a certain sub-part of the dCDN footprint
-- Yannick: no use in announcing a footprint without saying the associated capabilities
-- suggestion from Francois to base the discussion and way forward on some key use cases we all agree on
-- Jon: only on-net or only off-net use case are simple, the interesting use case is where you have both mixed; Francois: this is the use case I am proposing (mixed on-net and off-net)
-- Yannick: default footprint is "everywhere"; Jon: new interesting idea
-- agreement that we are talking about an interface that has the goal of updating the uCDN about recent changes in capabilities
-- Gilles: the tie-breaking information will be outside of the interface we are talking about (e.g. business)
-- Francois: interface may provide "additional hints" for the uCDN selection algorithm, let's rather call it that and not tie-breaker
-- Rich: what does the uCDN have to have to find dCDN candidates is what is important
-- Kevin: let's not define hints yet
-- Jon: delivery protocol is mandatory, agreement on this
-- Gilles: there is a difference between binary supported/non-supported capabilities and value-range capabilities
-- Kevin: support of metadata-bundles is mandatory capability
-- Kevin: what about security parameters?
-- Ray: what about CDNI features that are supported? (like DNS based request routing); Jan: is that part of the control interface or part of the request routing interface?
-- Rich: still open issues regarding footprint
-- agreement to focus on key use cases
**************

---

From: Songhaibin <[email-masked]>
Date: Thu, 2 Aug 2012 21:46:36 +0000

Good discussion. I'm sorry that I missed it. I agree that capability should be tied with footprint. IMO we need to answer to basic questions, then the footprint/capbility interface can be clear.

a. What factors will impact a particular CDN's footprint? 
     Is it the surrogate's topoligical distance to the content requester?  Or is it the performance requirements (e.g. for streaming, the average response time, and startup delay...) that should be satisfied for the application client? Or is it the geographical position of the CDN's surrogates? Or is it the capabilities about how many concurent requests this CDN can handle?

b. then How to represent this footprint?
    This is obviously less important for now.

-Haibin

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jan Seedorf [[email-masked]]
Sent: Friday, August 03, 2012 1:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84

Dear all,

 - Jan

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: Scott Wainner <[email-masked]>
Date: Mon, 06 Aug 2012 10:05:51 -0400

My apologies for not being able to join you in Vancouver.

My interpretation of the Use Cases with regards to geography:

     2.1 uCDN with limited geographic scope refers to a global dCDN
     2.3 uCDN with limited geographic scope refers to a another dCDN 
with limited geographic scope
     2.2 uCDN with global geographic scope refers to a dCDN with limited 
geographic scope

In none of the 2.x Use Cases do we define any capability limitations.  
There seems to be an assumption that the delegate CDN can do anything 
the uCDN can do.  I certainly don't believe that is true as others have 
noted below.  There seems to be an intrinsic requirement to correlate 
'footprint' with a 'capability'.

Independently we define a set of Use Cases in Section 4.x and we don't 
set conditions for the 'footprint'.

If we believe that the 'footprint' and 'capabilities' must now be 
correlated, do we need to determine the order of dependency?

Example with Footprint Dependency:
   Footprint A (AS_A or Prefix_A)
      Capabilities 1 (HTTP DASH)
      Capabilities 2 (HTTP HLS)
      Capabilities 3 (HTTP HSS)
   Footprint B (AS_B or Prefix_B)
      Capabilities 2 (HTTP HLS)

Or do you use the reverse using Capability dependency as follows:

   Capability 1 (HTTP DASH)
      Footprint A (AS_A or Prefix_A)
   Capability 2 (HTTP HLS)
      Footprint A (AS_A or Prefix_A)
      Footprint B (AS_B or Prefix_B)
   Capability 3 (HTTP HSS)
      Footprint A (AS_A or Prefix_A)

I suspect the capabilities will get a lot more complicated (URL Signing, 
Delivery Protocol, Delegation Method (DNS-I, DNS-R, HTTP-I, HTTP-R).  
Any thoughts on the appropriate order of dependency?

Scott

On 8/2/12 1:55 PM, Jan Seedorf wrote:
> .

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 6 Aug 2012 12:10:38 -0400

Hi Scott,

  I think that footprint can be used for other purposes besides describing,
  capabilities, but that capabilities may need footprint restrictions.  The
  draft I submitted deals with the latter.  The former seems to become more
  entangled with quality.  imo, the two should probably be separated, i.e.,
  capabilities tell if a CDN is technologically capable of handling a given
  request, while there may be other footprint related information which can
  describe how (physically) well the request can be handled.  That question
  of "how well" is a much harder problem which was discussed at length...

thanx.

-- Kevin J. Ma

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Wainner
> Sent: Monday, August 06, 2012 10:06 AM
> To: [email-masked]
> Subject: Re: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design
> team side meeting at IETF-84
> 
> > Here are my notes from yesterday's second footprint/capabilities design
> team side meeting. The same disclaimer applies ("...probably have not
> captured everything and admittedly the notes are rough in some cases").
> Thanks to everyone for taking the time and the (in my view) productive
> discussion.
> >
> >   - Jan
> >
> >
> > -- Kevin: let's start with global capabilities first, and look later on
> capabilities that are only valid for a partial footprint
> > -- Jan: do we all agree that there is kind of a generically valid
> contract, and the interface we are taking about is for giving additional
> update information with respect to such a contract?
> > -- Yannick: footprint and capabilities are tied together, does not make
> sense to announce a capability, if you do not say along for which
> footprint it is valid
> > -- agreement on problem we are trying to solve --> provide additional
> update information about capabilities that have changed/been added since
> the contract
> > -- agreement that footprint and capabilities are tied together --> given
> capabilities may apply only to a certain sub-part of the dCDN footprint
> > -- Jon: only on-net or only off-net use case are simple, the interesting
> use case is where you have both mixed; Francois: this is the use case I am
> proposing (mixed on-net and off-net)
> > -- agreement that we are talking about an interface that has the goal of
> updating the uCDN about recent changes in capabilities
> > -- Francois: interface may provide "additional hints" for the uCDN
> selection algorithm, let's rather call it that and not tie-breaker
> > -- Gilles: there is a difference between binary supported/non-supported
> capabilities and value-range capabilities
> > -- Ray: what about CDNI features that are supported? (like DNS based
> request routing); Jan: is that part of the control interface or part of
> the request routing interface?