Subject: [CDNi] comments on problem statement

From: Kevin J Ma <[email-masked]>
Date: Fri, 4 Mar 2011 16:14:59 -0500

Hi all,

  I've been trying to catch up with the list archive and the drafts,
  but I'll apologize in advance for any rehash.  Enclosed below are
  comments and questions on the problem statement; separate email to
  follow with questions and comments on the requirements.

thanx!

--  Kevin J. Ma

Problem Statement Comments/Questions:

1. Deletion is an important issue, and I know it has been discussed,
   but I had some additional comments:

   In Section 1.1, the CDNI Metadata definition states that:

   "... CDNI Metadata may also include content management
    information (e.g. request for deletion of Content from Surrogates)
    across interconnected CDNs."

   In Section 5, however, deletion is referred to as a CDNI Control API:

   "... the base capabilities of the CDNI Control API
    (e.g. content file/metadata deletion)"

   a) A request for deletion seems more like an action, than metadata?
      Similarly, a request for pre-positioning of content is an action,
      not metadata.  Are actions intended to be represented as metadata
      (e.g., as an expiration or activation time, respectively)?

   b) Is an additional class of Content Control APIs warrented here?
      Though it may contain a limited set of actions, the enforcement
      policies around those actions should probably be well defined?

   c) Is it intended that the CDNI Control API should negotiate SLAs
      for the enforcement of implied actions for individual metadata
      (e.g., the CDN will purge withing 5 min of the expiration time)?
      It might be good to note that in Section 4.6 CDNI Control API?

   d) It might also be good to mention confirmation messages for any
      asynchronous operations (e.g., surrogate purge/invalidate/delete)
      in Section 4.5 CDNI Logging API?

2. I don't know if this has been discussed, but I wanted to bring up
   workflow managers, and the need for administrative APIs.  The
   current CDNI Control API seems focused on interactions between CDNs
   to manage delivery, however, the policies for a given piece of
   content will typically be managed by a separate content workflow
   management entity, which will need access to the logging, control,
   and metadata APIs (but probably not request routing).  Additional
   APIs may be necessary for managing SLAs and logistics related to
   the source content and Authoritative CDNs.  Is this considered to
   be within the scope of CDNI?

3. In Section 1.1, a nit on the definition of OTT:

   "Over-the-top (OTT): A service, e.g. a CDN, operated by a different
    operator than the NSP to which the users of that service are
    attached."

   I typically think of OTT as an adjective, not a noun, and of a CDN
   as an infrastructure or operator, not a service.  A possible
   rewording might be:

   "Over-the-top (OTT) Service: A service operated by a different
    operator than the NSP, e.g. a CDN, to which the users of that
    service are attached."

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 9 Mar 2011 14:35:49 +0000

Kevin,

Thanks for the comments, please see inline.

>    (e.g. content file/metadata deletion)"

We noticed that inconsistency as well and plan to address it in the next revision of the problem statement which we are hoping to get published before the cut-off on Monday.

>      (e.g., as an expiration or activation time, respectively)?

This is probably getting too far into specific solution details for where we are currently at (i.e. trying to obtain consensus to form a WG). In my view the actions are not metadata but the metadata interface could possibly be used to distribute details about the action. E.g. the control interface could "poke" someone to do something and the metadata interface could contain all the details of what they should do. But there are also other ways a solution could be built.

>      policies around those actions should probably be well defined?

I don't really understand what you are asking as the context is not clear to me - i.e. an additional class on top of what base class?

>      It might be good to note that in Section 4.6 CDNI Control API?

IMO no absolutely not. That would be a complete rat hole and in my opinion is something that will always be negotiated via an out of band business-led process so a technology solution is not required. i.e. when two CDNs contract with one another such SLAs will be negotiated and if one party cannot honour the requirement of the other then the business negotiation will break down. advertising such things over a technical interface would add no value over the business-negotiated contract between the parties.

>      in Section 4.5 CDNI Logging API?

Confirmation messages may not be required, there are several possible solutions to enable the requester to know whether their requested action has been performed or not and I think it is a detail of the solution design what options we bake into the solution.

>   be within the scope of CDNI?

The aim of a CDNI WG is not to solve the entire CDNI problem space. In IETF we should IMO solve the technical protocol issues. Integration of a CDN within an operator's various operational and workflow systems is out of scope for a CDNI WG.

>   as an infrastructure or operator, not a service.  A possible

I think it depends on your point of view, a CDN can be an infrastructure but people have made businesses out of offering CDN services. Having said that I'm OK with your re-wording below.

>    operator than the NSP, e.g. a CDN, to which the users of that

Ben

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 9 Mar 2011 11:30:00 -0500

Hi Ben,

  thanx for the responses.  additional clarification below:

> I don't really understand what you are asking as the context is not clear to
> me - i.e. an additional class on top of what base class?

I was referring to the CDNI Control APIs, and whether or not actions
such as delete or "poke" fell into the category of CDNI Control APIs,
or whether there was an additional type of API (thats not Metadata,
or Logging, or Request Routing, or Control as it is defined), which
encompass these types of actions.

> IMO no absolutely not. That would be a complete rat hole and in my opinion is
> something that will always be negotiated via an out of band business-led
> process so a technology solution is not required.

Understood.  My use of the term "negotiate" may have been misleading;
perhaps the term "advertise" would be a better term.  I was referring
to section 4.6 which states that one of the functionalities is to:

     "Allow the downstream CDN to communicate information about its
      delivery capabilities, resources and policies."

A delegation decision may be dependent upon the ability of the
downstream CDN to not only deliver the content, but to also purge the
content within a reasonable amount of time, at some point in the future?

> >   workflow managers, and the need for administrative APIs.
[snip]
> 
> The aim of a CDNI WG is not to solve the entire CDNI problem space. In IETF we
> should IMO solve the technical protocol issues. Integration of a CDN within an
> operator's various operational and workflow systems is out of scope for a CDNI
> WG.

I think that the Core APIs being defined have the potential to be very
powerful for workflow managers.  The CDNI Control API which is 
"less well defined than the other three CDNI interfaces at this time"
may ultimately meet all the needs of workflow management, as it
becomes more well defined.  I understand the desire to limit scope,
but I think this is a opportunity to give consideration to a use case
within the CDNI problem space.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Wednesday, March 09, 2011 9:36 AM
> To: Kevin J Ma
> Cc: [email-masked]
> Subject: Re: [CDNi] comments on problem statement
> 
> Kevin,
> 
> We noticed that inconsistency as well and plan to address it in the next
> revision of the problem statement which we are hoping to get published before
> the cut-off on Monday.
> 
> This is probably getting too far into specific solution details for where we
> are currently at (i.e. trying to obtain consensus to form a WG). In my view
> the actions are not metadata but the metadata interface could possibly be used
> to distribute details about the action. E.g. the control interface could
> "poke" someone to do something and the metadata interface could contain all
> the details of what they should do. But there are also other ways a solution
> could be built.
> 
> 
> I don't really understand what you are asking as the context is not clear to
> me - i.e. an additional class on top of what base class?
> 
> IMO no absolutely not. That would be a complete rat hole and in my opinion is
> something that will always be negotiated via an out of band business-led
> process so a technology solution is not required. i.e. when two CDNs contract
> with one another such SLAs will be negotiated and if one party cannot honour
> the requirement of the other then the business negotiation will break down.
> advertising such things over a technical interface would add no value over the
> business-negotiated contract between the parties.
> 
> 
> Confirmation messages may not be required, there are several possible
> solutions to enable the requester to know whether their requested action has
> been performed or not and I think it is a detail of the solution design what
> options we bake into the solution.
> 
> 
> The aim of a CDNI WG is not to solve the entire CDNI problem space. In IETF we
> should IMO solve the technical protocol issues. Integration of a CDN within an
> operator's various operational and workflow systems is out of scope for a CDNI
> WG.
> 
> 
> I think it depends on your point of view, a CDN can be an infrastructure but
> people have made businesses out of offering CDN services. Having said that I'm
> OK with your re-wording below.
> 
>

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Wed, 9 Mar 2011 23:32:57 +0000

> encompass these types of actions.

I think that is something we can postpone until we start the actual solution work. IMO deletion/invalidation is the most important control function to automate, the rest of the described control API is "nice to have" but not critical day one.

> content within a reasonable amount of time, at some point in the future?

Consider the reality of how CDNI will be deployed. IMO CDNs aren't just going to turn up "peerings" with one another without first going through some level of business/contract negotiation. It is at that non-technical stage that SLAs will be negotiated and agreed. I seriously doubt that it needs to be exposed at "run time". i.e. I seriously doubt a scenario of Content A needs to be purged within 5 minutes but content B can be purged within 15 minutes and therefore there is no requirement to expose that level of capability via a technical solution. CDN A may have a high level requirement of "following sending a purge request content must be purged within X minutes" but that can be dealt with through an SLA negotiated prior to any "peering" being enabled. If CDN B can't meet that requirement then A and B will not interconnect with one another at least for the purpose of CDN A delegating to CDN B.

Ben

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 9 Mar 2011 19:27:24 -0500

> that can
> be dealt with through an SLA negotiated prior to any "peering" being enabled.
> If CDN B can't meet that requirement then A and B will not interconnect with
> one another at least for the purpose of CDN A delegating to CDN B.

Just to make sure that I am interpreting this correctly, does this imply
that the CSP will have pre-negotiated with A and B, out-of-band, and then
will have given explicit permission to A, to delegate to B?

Is it fair to say that CDNI assumes that the CSP has explicitly stated its
trust, a priori, for all CDNs involved in the interconnection?

Section 9 states: "the CSP "trusts" a CDN that "trusts" another CDN",
which I interpreted as a delegation of trust, requiring a mechanism for
negotiating/advertising SLA type information.  Would it be more correct
to say that the CSP "trusts" A and the CSP "trusts" B, therefore an
implied trust between A and B exists, and therefore A may delegate to B?

thanx again.

--  Kevin J. Ma

> From: Benjamin Niven-Jenkins [mailto:[email-masked]]
> Sent: Wednesday, March 09, 2011 6:33 PM
> To: Kevin J Ma
> Cc: [email-masked]
> I think that is something we can postpone until we start the actual solution
> work. IMO deletion/invalidation is the most important control function to
> automate, the rest of the described control API is "nice to have" but not
> critical day one.
> 
> Consider the reality of how CDNI will be deployed. IMO CDNs aren't just going
> to turn up "peerings" with one another without first going through some level
> of business/contract negotiation. It is at that non-technical stage that SLAs
> will be negotiated and agreed. I seriously doubt that it needs to be exposed
> at "run time". i.e. I seriously doubt a scenario of Content A needs to be
> purged within 5 minutes but content B can be purged within 15 minutes and
> therefore there is no requirement to expose that level of capability via a
> technical solution. CDN A may have a high level requirement of "following
> sending a purge request content must be purged within X minutes" but that can
> be dealt with through an SLA negotiated prior to any "peering" being enabled.
> If CDN B can't meet that requirement then A and B will not interconnect with
> one another at least for the purpose of CDN A delegating to CDN B.
> 
> Ben

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Thu, 10 Mar 2011 08:26:33 +0000

Kevin,

The non-technical aspects of CDNI are out of scope for a WG and there are multiple ways CDN operators and CSPs may negotiate contracts so let's try and avoid a protracted discussion on this topic. However I think it's worth responding as I'm trying to avoid us building unnecessary technology...

See inline.

> will have given explicit permission to A, to delegate to B?

No. I was thinking of a model where the CSP pre-negotiates with A and A negotiates with B factoring in the CSP's requirements into that A-B negotiation.

> negotiating/advertising SLA type information.

It is a delegation of trust but we do not require a technical solution to negotiate/advertise SLA type information IMO.

Let me draw a parallel with Layer 3 Virtual Private Networks (L3VPNs) as that is an area unrelated to CDNs I have some experience with where the technology is defined in the L3VPN WG which has been deployed by a significant number of network operators and which has global revenues in the tens of billions of dollars annually.

Many network operators do not have a completely global L3VPN footprint and even those that can reach a significant proportion of the globe often do not have significant in-country footprint in specific regions. In order to extend their footprint some operators interconnect their L3VPNs. We defined the technology to do that in the L3VPN WG at IETF. However we did not define any technology to negotiate SLAs, QoS policies etc.

What happens in the market is L3VPN provider A negotiates with L3VPN provider B to interconnect their networks and as part of that out-of-band negotiation they agree amongst other things what SLAs one will offer the other, how one will implement the QoS policy of the other, etc. Then multi-national Corporate Customer X contracts with L3VPN Provider A for network connectivity between their sites across the world and A may use its interconnect with B to reach some of X's sites. X trusts A and A trusts B but X does not have any direct relationship with B. Equally their is no technology solution for A and B to negotiate SLAs or QoS policies or for B to advertise available capacity to A etc. It is not needed as it was negotiated out of band prior to their networks being interconnected.

I see CDNI as similar in that regard and therefore we don't need technology to negotiate things like SLAs as typically they are wrapped up in a much more complex out-of-band negotiation/contractual process that happens in advance of any interconnects being turned up or any CSPs signing contracts for delivery to that region or network.

HTH
Ben

>  Would it be more correct

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 10 Mar 2011 14:19:26 +0100

Folks,

> No. I was thinking of a model where the CSP pre-negotiates with A and A negotiates with B factoring in the CSP's requirements into that A-B negotiation.

Same here. 
To me this is a pretty fundamental assumption of our CDNi model that it supports a mode of operation where the CSP does not have to contract with, and does not even have to aware of, downstream CDNs; and where the CSP only needs to contract with, and interwork with, the Upstream CDN (aka the "Authoritative CDN"). 

> It is a delegation of trust but we do not require a technical solution to negotiate/advertise SLA type information IMO.

I also don't see a requirement for advertising/negotiating detailed SLA parameters (at least in the initial solution).
As noted earlier in this thread, there may be a need for advertising some base capabilities. It is TBD how much of that is to come in the initial scope of a potential WG.

Francois

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

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 10 Mar 2011 10:11:52 -0500

Ben

  I appreciate the detailed discussion.  I understand your position now.

thanx.

--  Kevin J. Ma

> Sent: Thursday, March 10, 2011 3:27 AM
> To: Kevin J Ma
> Cc: [email-masked]
> The non-technical aspects of CDNI are out of scope for a WG and there are
> multiple ways CDN operators and CSPs may negotiate contracts so let's try and
> avoid a protracted discussion on this topic. However I think it's worth
> responding as I'm trying to avoid us building unnecessary technology...
> 
> See inline.
> 
> No. I was thinking of a model where the CSP pre-negotiates with A and A
> negotiates with B factoring in the CSP's requirements into that A-B
> negotiation.
> 
> It is a delegation of trust but we do not require a technical solution to
> negotiate/advertise SLA type information IMO.
> 
> Let me draw a parallel with Layer 3 Virtual Private Networks (L3VPNs) as that
> is an area unrelated to CDNs I have some experience with where the technology
> is defined in the L3VPN WG which has been deployed by a significant number of
> network operators and which has global revenues in the tens of billions of
> dollars annually.
> 
> Many network operators do not have a completely global L3VPN footprint and
> even those that can reach a significant proportion of the globe often do not
> have significant in-country footprint in specific regions. In order to extend
> their footprint some operators interconnect their L3VPNs. We defined the
> technology to do that in the L3VPN WG at IETF. However we did not define any
> technology to negotiate SLAs, QoS policies etc.
> 
> What happens in the market is L3VPN provider A negotiates with L3VPN provider
> B to interconnect their networks and as part of that out-of-band negotiation
> they agree amongst other things what SLAs one will offer the other, how one
> will implement the QoS policy of the other, etc. Then multi-national Corporate
> Customer X contracts with L3VPN Provider A for network connectivity between
> their sites across the world and A may use its interconnect with B to reach
> some of X's sites. X trusts A and A trusts B but X does not have any direct
> relationship with B. Equally their is no technology solution for A and B to
> negotiate SLAs or QoS policies or for B to advertise available capacity to A
> etc. It is not needed as it was negotiated out of band prior to their networks
> being interconnected.
> 
> I see CDNI as similar in that regard and therefore we don't need technology to
> negotiate things like SLAs as typically they are wrapped up in a much more
> complex out-of-band negotiation/contractual process that happens in advance of
> any interconnects being turned up or any CSPs signing contracts for delivery
> to that region or network.
> 
> HTH
> Ben
> 
> 
> 
> >  Would it be more correct
> >>>> IMO no absolutely not. That would be a complete rat hole and in my
> opinion
> >> is

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 11 Mar 2011 19:45:14 -0500

Francois/Ben,

> To me this is a pretty fundamental assumption of our CDNi model that it supports a mode of operation where the CSP does not have to contract with, and does not even have to aware of, downstream CDN…

  I think supporting a mode with a single authoritative CDN is good,
  however, this single authoritative CDN mode should not be the only
  mode supported.  Some premium content providers might be reluctant
  to migrate to a single authoritative CDN, and some business models
  require CDN selection and delegation to conform to business rules,
  e.g., content aggregators/clearing houses which may have different
  distribution rules for different publishers, and services that use
  authentication-based CDN affinity.

  I can see use cases where premium content providers wish to retain
  control over delegation policies.  Given a sufficiently expressive
  set of supported metadata, CDNI APIs could be used for configuring
  CDNs based on business rules and managing multiple CDNs.

  We compiled a short list of publisher use cases in an I-D:
    draft-ma-cdni-publisher-use-cases-00
  Many of them have already been discussed in the email threads, but
  we feel that the workflow management use cases represent important
  modes of operation which content providers are interested in.

thanx.

--  Kevin J. Ma

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Thursday, March 10, 2011 8:19 AM
To: Benjamin Niven-Jenkins; Kevin J Ma
Cc: Le Faucheur Francois; [email-masked]
Subject: Re: [CDNi] comments on problem statement

Folks,

that can

Same here.

Francois

HTH
Ben

Would it be more correct

thanx again.

--  Kevin J. Ma

-----Original Message-----
From: Benjamin Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, March 09, 2011 6:33 PM
To: Kevin J Ma
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] comments on problem statement

Hi Ben,

I don't really understand what you are asking as the context is not clear
to
me - i.e. an additional class on top of what base class?

IMO no absolutely not. That would be a complete rat hole and in my opinion
is
something that will always be negotiated via an out of band business-led
process so a technology solution is not required.

Ben

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

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]<mailto:[email-masked]>
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com<http://www.cisco.com>

 Think before you print.

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Sat, 12 Mar 2011 20:35:30 +0000

Kevin,

>   authentication-based CDN affinity.

Let me be a little more precise than I may have been earlier. For a given request there should be a single authoritative CDN. If a CSP wishes to maintain relationships with multiple CDNs then that is OK and is outside the scope of CDNI. CDNI does not prevent them doing so and a CSP maintaining multiple business relationships with different CDNs and selecting different CDNs at different times does not IMO place additional requirements onto CDNI solutions.
 
>   CDNs based on business rules and managing multiple CDNs.

This is probably where we differ in opinion. I am of the view that content providers wish to retain the control you mention but that we should not try to make CDNI support very complex expressions of policy. Rather CDNI should support relatively straightforward policy expressions and if a CSP wants something more complex they can do that out of band with their authoritative CDN(s). Their authoritative CDN(s) can then ensure they delegate appropriately (if at all) based on their knowledge (obtained out of band) of of the policies of their downstream CDNs.

What that would mean is that a CSP could always have their restrictive policy enforced but with the consequence that the number of downstream CDNs available to them may be more restricted than if CDNI supported very complex expressions of policy. I believe that additional restriction to be acceptable because the alternative is that everyone is overburdened with supporting very complex policy expressions which are not required for the vast majority of cases.

Furthermore IMO when it comes to implementing complex policies it is my experience that companies and individuals tend to prefer a contractual rather than technical solution and so I believe such cases can be handled with upfront configuration rather than complex policy computation at "redirect time".
 
>   modes of operation which content providers are interested in.

Thanks for taking the time to write the draft, it contains some useful insights.

One comment on section 4.1:
                                                           When
        delegating requests for HLS content, it may not be efficient to
        delegate each segment file request, but rather be able to
        delegate sets of content files  that are commonly requested as a
        group.

FWIW depending on how a CSP constructs & delivers their "manifest" files this can be achieved today either through DNS TTLs or by leveraging the defined HTTP behaviour for HTTP redirects. I see it as a valuable requirement but more applicable to CDNs in general rather than to CDNI specifically.

Ben