Subject: [CDNi] Fwd: Some comments on draft-bertrand-cdni-use-cases-01

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 11:29:35 +0000

Colleagues,

I originally intended to send the comments below to the list, but forgot to cc [email-masked] so I am forwarding them now.

Ben

Begin forwarded message:

> From: Ben Niven-Jenkins <[email-masked]>
> Date: 1 February 2011 10:01:05 GMT
> To: <[email-masked]> <[email-masked]>
> Subject: Some comments on draft-bertrand-cdni-use-cases-01
> 
> Gilles, Colleagues,
> 
> I read the -01 version of draft-bertrand-cdni-use-cases and had a couple
> of questions and comments which I have included below. I have quoted some
> parts of the draft to provide context and then put my comment or question
> underneath.
> 
> 
> 2.1.3.  Nomadic Users
> 
>   Another scenario is nomadic situation.  In this scenario a CSP wishes
>   to allow users who move to other geographic regions to continue to
>   access their content.  The motivation in this case is to allow
>   nomadic users to maintain access, rather than to allow all residents
>   within a region access to the content.
> 
> 
> From a purely technical perspective I wonder if the nomadic use case
> actually differs from the geographic extension use case? i.e. Does the
> nomadic use case introduce any new requirements onto the solution?
> 
> Although the text implies a need for a mechanism to restrict access to
> just nomadic users and prevent ³all residents within a region² having
> access I would expect that even in the geographic extension use case there
> would be a requirement to be able to restrict access to a subset of the
> total user population  e.g. only those users who had previously
> authenticated to the CSP¹s service.
> 
> 
> I still think it is worth separately describing the nomadic use case in
> the draft but am I correct in assuming that by itself it doesn't introduce
> any specific requirements that would need to be captured?
> 
> 
> 2.1.5.  Device and Network Technology Extension
> 
>   In this use case the CDSP may have the geographic and end-user
>   coverage that it requires, but wishes to support the delivery of
>   content to alternative end devices.  These devices may sit on remote
>   networks (such as smartphones connected to a mobile network) and may
>   also require unique delivery capabilities in the CDN.  In this case
>   the CDSP may federate with another CDSP that offers service to these
>   Devices.
> 
> 
> I might be being pedantic but is it the device that requires unique
> delivery capabilities or is it that the device only speaks certain
> protocols and ³delivery capabilities in the CDN² really means ³the CDN
> must support delivery protocol X²?
> 
> 
> The effort required to specifying how to describe different delivery
> protocols & which CDNs support them is much reduced compared to specifying
> how to describe the multitude of different devices and their individual
> capabilities.
> 
> 
> 2.2.2.   Resiliency
> 
>   ...
>   Resiliency may also be required against failure to ingest content
>   from the CSP.  In these cases the content may be available from
>   another CDSP.
> 
> 
> 
> I think it would be useful if you could try and expand on the part of the
> resiliency use case related to failures like this as I suspect there may
> be some additional
> requirements hiding under the surface.
> 
> For example, is there an assumption that the downstream CDN already has
> the content, or is there an assumption that the failure that meant the
> upstream CDN could not ingest the content does not impact the downstream
> CDN's ability to ingest from the same CSP?
> 
> 
> 
> 2.4.1.  NSP CDSP Use Case
> 
>   In a interconnection use case, CDSP-A is likely to offer an SLA to
>   the CSP including performance or other quality metrics.  If it cannot
>   meet the SLA it will push content via the interconnection to a CDSP-B
>   with CDN capabilities that are in a position to guaranty the SLA, and
>   redirect users appropriately to CDSP-B.  CDSP-A may not be able to,
>   or may not wish to deploy its own CDN capabilities to meet the SLA
>   requirements for only a subset of its CSP customers.  The ability to
>   offer stringent delivery quality SLAs is a differentiator against
>   other CDSPs and can be sold as a premium service.
> 
> 
> I think it would be useful if you could try and outline how much of this
> use case you would expect (or require) to be solved technically Vs some
> other channel (e.g. out of band commercial agreements between CDSPs). That
> would help to steer the technical requirement gathering and help keep the
> scope of the problem space well defined.
> 
> 
> 3.2.  Gaps in Existing Solutions and Need for Specifications
> 
> 
> This section mentions three limitations that were discovered during your
> experiments, I wonder whether they were knock-on effects of those initial
> limitations that it would be worthwhile to describe, for example (and this
> is a made up example) having to define target URLs manually between CDNs
> may have meant that some common CDN features like token/url authorisation
> could not be used. Describing such knock-on effects would be useful as we
> can ensure the CDNI solution addresses those as well as the first order
> requirements.
> 
> (Of course you may not want to reveal all the details of the limitations
> your experiments found and if that's the case, that's OK with me but you
> should still try to ensure the requirements document adequately covers
> those use cases).
> 
> 
> 
> Regards
> Ben
> 
>

---

From: <[email-masked]>
Date: Wed, 2 Feb 2011 15:04:33 +0000

Thanks for the comments Ben - some replies below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ben Niven-Jenkins
> Sent: 01 February 2011 11:30
> To: [email-masked]
> Subject: [CDNi] Fwd: Some comments on draft-bertrand-cdni-use-cases-01
> 
> Colleagues,
> 
> I originally intended to send the comments below to the list, but
> forgot to cc [email-masked] so I am forwarding them now.
> 
> Ben
> 
> 
> Begin forwarded message:
> 

No I don't think it differs much. In fact, most of the use cases are very similar if you start looking at technical requirements.

> > authenticated to the CSP¹s service.

As you say the difference is in the Metadata that controls the distribution. There are probably quite a few scenarios that require a highly expressive language for the distribution policy. I think standardising things like the policy language could be one of the more difficult challenges, and certainly one where we have to integrate as much as possible with other industry bodies.

> > any specific requirements that would need to be captured?

We're going through the requirements document now and haven't noticed any glaring omissions that would be required by the use cases we describe.

> > must support delivery protocol X²?

Well the CDN requirement would certainly be phrased as you suggest. In technical terms, again there isn't a huge difference - impacts on how expressive the capabilities description is through the control API. This might include network speed and characteristics, protocols supported, as well as things like screen size and even processing power. Some network characteristics, some surrogate delivery mechanisms, some device capabilities.

> > how to describe the multitude of different devices and their

Yes, but you may need to know about the devices (at least at some level) - for example, there's no point in moving a certain encoding to a downstream CDN if you know that if has no devices that require it. I'm not suggested compiling lists of all devices, but these might be rolled into the CDN capabilities at some level.

> > scope of the problem space well defined.

Once again I think it's in the fine detail of metadata and policies. Content metadata might specify SLA delivery criteria. Logging would have to be able to capture similar parameters to measure performance against SLA. CDN capabilities would need to specify performance guarantees or estimates to allow an upstream CDN to make an appropriate request routing decision to maintain it's SLA agreements.

Since the content acquisition (and certainly the business contract) with the CSP is out of scope we don't need to worry about the negotiation of the SLA with the CSP.

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

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Sun, 6 Feb 2011 11:36:09 +0000

Trevor,

Thanks for the response, see inline below.

> As you say the difference is in the Metadata that controls the distribution. There are probably quite a few scenarios that require a highly expressive language for the distribution policy. I think…

Personally I don't think the language needs to that expressive.

Distribution policy is typically controlled by the CSP. From the point of view of a CSP they can typically express their preferences in fairly simple terms, i.e. split into rules for "serving" and rules for "delivery" which when combined express their requirements.

Serving rules are typically of the form
- I don't care where you store & serve my content from as long as my users/customers can access it
- I do care where you store & serve my content from and either:
  - You must not store/serve it from these locations (which are typically a geographic region, e.g. country/city/metro area)
  - You must only store/serve it from these locations.

Delivery rules are typically of the form
- I don't care where the user is.
- I do care where the user is and either:
  - They must not be in these locations (typically geographic regions, countries/cities/metro areas) 
  - They must only be in these locations

Plus:
- Regardless of my other delivery preferences these ranges of IP addresses can always have access (e.g. the CSP's QA team may be located in a region they typically do not want the CDN to deliver to)
- On top of the CSPs other delivery preferences ensure the user has been previously authenticated via the CSPs service layer (portal, middleware, etc.)

All the above can be reduced to and expressed as a pair of access control lists, one for distribution & one for delivery, where the key variables are how one describes locations and how one indicates a user is appropriately authenticated.

It may be tempting to try to make the policy language more expressive than an ordered list of locations plus allow/deny/must-be-authenticated actions but I have yet to see a requirement from a CSP that can not be suitably addressed/met using such a pair of distribution+delivery access control lists.

> Yes, but you may need to know about the devices (at least at some level) - for example, there's no point in moving a certain encoding to a downstream CDN if you know that if has no devices that req…

We need to be careful not to try and overload the CDN with functions and responsibilities that are better placed elsewhere. Knowledge of "screen size", "encodings" and "device types" for example largely sit outside of the CDN. The CDN delivers what the CSP tells it to. The ultimate choice of the appropriate version of content to deliver (i.e. screen size/encoding/format for particular device) should sit with the CSP not with the CDN as the CDN only has a limited ability to determine those things. The End User (via their user agent) will in the vast majority of cases have interacted with the CSP's service layer (portal, middleware, etc.) prior to being redirected to the CDN and the CSP's service layer has much better knowledge of the user's preferences and device capabilities than the CDN does. Getting it wrong means that the user goes away with a poor experience of the CSP not of the CDN (as the CDN is largely invisible to all but the most technically minded users).

The analogy I'd draw (which may or may not work) is that of a mail order movie rental company. The movie rental company (i.e. the CSP) is in the best position to know whether you typically like to receive VHS, DVD or Blueray movies (either because you've told them or from previous order history). The courier (i.e. the CDN) who delivers the movie to your home typically has very little ability to make that determination.

Ben

---

From: Francois Le Faucheur <[email-masked]>
Date: Sun, 6 Feb 2011 16:27:45 +0100

Ben, Trevor,

> It may be tempting to try to make the policy language more expressive than an ordered list of locations plus allow/deny/must-be-authenticated actions but I have yet to see a requirement from a CSP…

That looks like a good base to start from for the "geo-blocking/authentication" angle. I would just add the  "availability window" of R53 ie:
" 
"availability window" (i.e. Information defining time windows during which the content is to be made available or blocked)
"

Let's start with these and see if someone makes a clear case for additional requirements.

Francois