Subject: [CDNi] Notes and summary of yesterday's footprint/capabilities design team call

From: Jan Seedorf <[email-masked]>
Date: Wed, 10 Oct 2012 12:56:38 +0000

Hi all,

Below are detailed notes from yesterday's footprint/capabilities design team call. Many thanks to Enrico for taking the notes. Let me briefly summarize the discussion and the next steps:
-- first we recapped the things we had agreed on (or at least largely agreed on) in Vancouver and the open issues.
-- Regarding footprint, agreement has been found on some issues (see the slides I presented at the CDNI session at IETF-84 for a summary), but there are still some open issues: a) what exactly is a footprint and how can it be derived in practice? What information needs to be "tagged along" with a footprint to prevent the "I can cover the whole world" problem, and is this additional information being agreed in contracts (out of scope if our work) or within the CDNI RR interface?
-- Regarding capabilities, we continued the discussion we had at a side meeting in Vancouver. There is agreement that capabilities are mostly going to be agreed in contracts, but the CDNI protocol can be used to "update" a uCDN when things have changed. Since things can change only for a part of a footprint, capabilities and footprint are likely to be tied together in some cases. We do not know much how actual CDNI contracts will look like at this point in time, so the challenge is to agree on a small set of capabilities that we think will be mandatory in any case. In order to make progress with this challenge, we agreed to focus on some key use cases. These use cases should however not be simple / straightforward ones, but rather some interesting/challenging ones.
-- Several such use cases were raised in the call by various participants and discussed. We agreed to circulate these use cases on this list to discuss them and particular find out where they overlap or are actually subcases of each other. The plan is to have this discussion on the list (with everybody who has an interesting use case sending it on the list), so that we hopefully carve out 2-3 key use cases by the next call.

Thanks to all for participating and an interesting discussion. If you thing the above is missing a key point or misleading, please comment in this list.

Next call is next Tuesday, 16:00-18:00. I will circulate the WebEx details again.

 - Jan

************************************
Meeting starts at 16:10 CEST.

Jan recaps.

  Agreed: footprint is willingness to serve. But it's not enough. Need
  to find something more.

  Agreed: much will be decided in contractual agreements.

  Agreed: dcdn updates ucdn when something changed.

  Agreed: monetary costs are out of scope.

  Open question: what exactly is footprint?

  Open question: what's the missing part other than what's defined in
  contractual agreements?

  Open question: what capabilities are useful?

  Agreed: capabilities will be negotiated in the contract, the
  protocol will provide updates according to them.

  Open question: tie-breaking information. Quite agreed that will have
  to do with economics.

Jon: Capabilities and footprint are tied together.

[Interruption]

  We need to figure out the distinction between capabilities and
  footprint over the wire.

Jan: Need to understand what information will be useful.

Jon: We can't figure out what contracts will look like. Suggest to
  define something simple and extensible.

Jan: What do others think?

[No one comments]

Jon: Lot of key people missing.

Jan: Progress would be to identify mandatory capabilities.

Jon: Willing to trade interoperability with flexibility at this time.

Jan: Agreed. If there would be an easily agreeable mandatory set of features at
  this point we would have identified that.

Jon: Should we go through the use-cases exercise?

Jan: If we go there, let's skip the basic ones.

Jon: If we consider only the on-net use case, that would be easy.

Jan: More advanced use-cases raise questions that we cannot answer.

Jon: How the dcdn expresses it's ability to cover a particular area is
  the important issue here.

Scott: The protocol should help answer the question: "are you a
  candidate for serving that request?"

Jan: It was raised that tie-breaking info can be in the contract,
  maybe there's no need to have that in the protocol.

Scott: Two things are needed: the set of candidates and info for
  choosing among them.

Jon: The more realtime the information is, the less useful it is to
  advertise it.

Jon: Do we see a use case where a ucdn can decide more than one dcdn?

Scott: It is possible, but you're still using the same mechanism.

Jan: Agree that protocol-wise the dcdn process can return more than one.

Scott: The client gets one answer in the end.

Jon: In parallel forking in SIP you get the first valid response. This
  is strictly related to the request routing interface.

Jan: If rr return more than one, the ucdn can still pick the one it prefers.

Jon: Maybe we're just moving the line between advertizing and rr.

[Jon leaves]

Scott: I'd assume that between ucdn and dcdn there is one specific
  interface. Either there is one transaction or more in parallel, from
  an interface perpective things are the same.

Jan: If you involve two dcdns, you have to pay both.

Scott: Yeah, that's where economics get in place.

Anne Marrec: We need to allow only one dcdn.

Scott: What people do today is HTTP and DNS redirect, and in that case
  you need to pick one.

Jan: I agree that the footprint advertizing can return more than one.

Anne: Do you consider one agreement between ucdn and dcdn or more?

Jan: I guess there would be one contract.

Anne: There could be several, based on contract. A dcdn can have an
  on-net contract and an off-net one.

Jan: We agreed that contracts are out-of-scope.

[Discussion about possible multiple contracts, whether they should be
seen as different dcdns, whether they can exist at all, ...]

Emile: Believe Anne's use case should be described in the draft.

Anne: We need to make some assumptions on which parameters are in the
  contract.

Jan: I agree that we need to address the distinction of what is going
  to be in the contract and what needs to be advertized through the
  footprint ad interface.

Emile: Stresses that a use case for different contracts for the same
  dcdn should be added.

Anne: Explains that an off-net dcdn can delegate to an on-net dcdn if
  requested. This would resolve in two sub-contracts.

Jan: I understand now. But what should matter is not whether the dcdn
  is on- or off-net, but the performance guaranteed.

Jan: Second consideration: what if the situation expressed in the
  contract changes, like e.g. after an hardware upgrade?

Scott: What is important is not the coverage, but the location of the
  dcdn caches. I can advertize the entire planet.

Jan: On that point there is agreement, willingness to serve is not
  enough, parameters are also important. And parameters will be bound
  to contractual clauses.

Anne: If advertizing changes often, that may overload the ucdn. Should
  be coarse-grained info.

Jan: The question is what is realistically feasible?

Scott: Let's identify what is the minimum. One use case is a global
  cdn that delegates to a local cdn that has caches in the region to
  be served. Another use case is an ucdn that is localized and get a
  request for a region far away. What's required to do that.

Jan: I agree that those are important use cases.

Enrico: Scott's use cases cover are the most intresting ones.

Jan: Suggest to describe them and have them written down.

Scott: Let's start from the two main use cases, and then other will
  follow from them.

Jan: Should we focus on describe the main use cases better?

Scott: Yes, and from there let's identify what are the mandatory
  pieces of information.

Jan: And there we'll try to draw a line between what will be in the
  protocol and what will be addressed by the contract.

Emile: Information necessary for making a decision are about the
  end-to-end quality information.

Scott: Realtime information cannot be signalled.

Jan: We agreed that it should be more averaged information.

Emile: Sort of disagrees. Need to be discussed.

Scott: Let's define what's strictly mandatory for making a decision.
  Everthing else can be set in configurations.

Jan: We should discuss the use cases on the list before we have the
  next meeting next Tuesday.

Meeting ends at 17:40 CEST.
************************************

============================================================
Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division     
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-221
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked]
============================================================
NEC Europe Limited Registered Office: NEC House,
1 Victoria Road, London W3 6BL Registered in England 2832014