Subject: [CDNi] CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 1 Aug 2012 14:05:09 +0000

Jan, Stefano, Jon,

I just wanted to reiterate the suggestion I made at the very end of the WG meeting Yesterday.

A possible way to make progress might be to:

	1) identify one, or a very small number, of use case(s) that we want the CDNI Footprint/Capabilities to support

	2) identify the semantics of the required information for this/these specific use cases.

While this approach may arguably not allow us to define the most flexible universal solution, it would have the merit of allowing us to define a solution addressing some part of the problem.

With respect to 1), I think the design team has already identified ISP CDNs and global CDNs as targeted dCDNs. So perhaps the use cases of focus could include something like:
	* the uCDN wants to use dCDN1 (CDN of ISP1) when the enduser is attached to a part of ISP1 and where ISP1 feels the request can be well served by on-net caches of ISP1 (an interesting flavor of this is where ISP1 has some of his AS not covered well by his own CDN - e.g. some remote territory)
	* the uCDN wants to use dCDN2 (CDN of ISP 2) when the enduser is attached to a part of ISP1 where ISP1 feels the request can _not_ be well served by on-net caches of ISP1 but where ISP2 claims that the request can be well served by CDN of ISP2 (because he has caches that - while not "on-net" on ISP1 - are well connected to ISP1 e.g. via many regional peering points)
	* the uCDN wants to use dCDN3 (a global CDN) when the enduser is attached to any other ISP network with whom dCDN3 is well interconnected (e.g. via many regional peering points)
	* the uCDN wants to use dCDN 4 (another global CDN) when the enduser is attached to an ISP network with whom dCDN3 is not well interconnected (e.g. via single centralized peering points)
I just made that up so it needs more thinking, but take is as an example of the sort of use case we may want to start from.  

I hope that helps

Francois

On 31 Jul 2012, at 18:05, Jan Seedorf wrote:

> Several people have indicated that they will come to this meeting, so: "it's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration desk to continue our discussions, trying to make some progress ...
> 
> - Jan
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:cdni-footprint-
>> [email-masked]] On Behalf Of Jan Seedorf
>> Sent: Wednesday, August 01, 2012 1:18 AM
>> To: [email-masked]
>> Cc: Brandenburg, R. (Ray) van ([email-masked]); Enrico
>> Marocco; [email-masked]; [email-masked]; Kevin J
>> Ma <[email-masked]> ([email-masked])
>> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabilities
>> Design Team Side Meeting at IETF-84
>> 
>> Guys,
>> 
>> Looking at the latest doodle it seems that actually *** WED 15:00-17:00 ***
>> would be a good slot where a reasonable amount of people can make it. So I
>> suggest having another CDNI Footprint/Capabilities Design Team Side
>> Meeting at this time.
>> 
>> Please confirm via email if you can actually make this slot, so that we see if it
>> really makes sense to have the meeting (i.e. all people that indicated so in
>> the doodle really coming).
>> 
>> - Jan
>> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 2 Aug 2012 05:18:56 +0800

Hi Francois,

Good suggestion. Jon also mentioned that we might want to reread the use
case draft, which contains many use cases already.

Before we pile in more use cases, I will give a try on the example use case
from your email, as the example already touches on some basic issues. In
particular, to handle the use case,  the uCDN needs the following info from
dCDN[1-4]:

- dCDN1 (ISP1)

  Set11 (good set) of dCDN1's home net -> QoE11
  Set12 (poor set) of dCDN1's home net -> QoE12

Implication 1: we need ip level encoding, as AS level (Set11 and Set12 may
not partition along the ASNs of ISP 1, or ISP1 has only one ASN) may not be
enough.

Implication 2: we need to come up with representation and semantics for
QoE11 and QoE12. One approach is true/false representation, where true
means willing-and-can-serve, and false means not willing-or-can-not.
However, this is too aggressive, as (1) poor QoE does not mean fully
useless; (2) poor or not depends on the request. For example, what I heard
is that audio needs 150 ms latency, video needs 200 ms; streaming depends
on the streaming rate, etc. Using the spirit of divide-and-conquer, may I
suggest that we identify a modular task of defining content delivery
performance characterization (syntax and semantics). Just as defining a
delivery logging format is a good *hopefully-reusable* "by-product" of CDNi
(independent of CDNi deployed or not), we have a smaller,
hopefully-reusable task than the larger footprint/capability advertisement
task, and we can move on, as long as we feel that there is a quite
reasonable chance that the subtask (defining content delivery performance
metrics) can be done. As a starting starting straw-man, I define:
propagation-delay bound (ms) [Mandatory]
max-supported-per-ua-streaming rate (Kbps) [M]
delay-jitter [O]

I feel that there are multiple experts on content delivery metrics and we
can define an initial set.

Now we go to dCDN2 (ISP2):

  Set21 of dCDN2 -> QoE21
  Set22 of dCDN2 -> QoE22
  ...

  Note that Set12 intersects with some Set2j.

...

Continue this example, an architecture/protocol issue we may face, while
the content delivery metrics group is working on the metrics, is how the
uCDN will aggregate the reported QoEs to propagate further. One way is the
BGP Best-Path design (applying filtering such as comparison with
internal/3rd party measurements) which essential reports a single QoE for
each IP. Another design is exposing multipaths by exposing multiple access
points. Clearly I support the multipaths design.

Richard

PS: I may suggest the failure/maintainence use case in the use-case draft
as a next case. As I see an RSVP style protocol flow will come out of it. I
also feel that the affiliation/migration use cases provide another type of
distinct use case (less privacy concern).

On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote:

>         1) identify one, or a very small number, of use case(s) that we
> want the CDNI Footprint/Capabilities to support
>
> While this approach may arguably not allow us to define the most flexible
> universal solution, it would have the merit of allowing us to define a
> solution addressing some part of the problem.
>
> With respect to 1), I think the design team has already identified ISP
> CDNs and global CDNs as targeted dCDNs. So perhaps the use cases of focus
> could include something like:
>         * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduser is
> attached to a part of ISP1 and where ISP1 feels the request can be well
> served by on-net caches of ISP1 (an interesting flavor of this is where
> ISP1 has some of his AS not covered well by his own CDN - e.g. some remote
> territory)
>         * the uCDN wants to use dCDN2 (CDN of ISP 2) when the enduser is
> attached to a part of ISP1 where ISP1 feels the request can _not_ be well
> served by on-net caches of ISP1 but where ISP2 claims that the request can
> be well served by CDN of ISP2 (because he has caches that - while not
> "on-net" on ISP1 - are well connected to ISP1 e.g. via many regional
> peering points)
>         * the uCDN wants to use dCDN3 (a global CDN) when the enduser is
> attached to any other ISP network with whom dCDN3 is well interconnected
> (e.g. via many regional peering points)
>         * the uCDN wants to use dCDN 4 (another global CDN) when the
> enduser is attached to an ISP network with whom dCDN3 is not well
> interconnected (e.g. via single centralized peering points)
> I just made that up so it needs more thinking, but take is as an example
> of the sort of use case we may want to start from.
>
> I hope that helps
>
> Francois
>
> > Several people have indicated that they will come to this meeting, so:
> "it's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration
> desk to continue our discussions, trying to make some progress ...
> >
> > - Jan
> >
> >> From: [email-masked] <javascript:;> [mailto:
> cdni-footprint- <javascript:;>
> >> [email-masked] <javascript:;>] On Behalf Of Jan Seedorf
> >> To: [email-masked] <javascript:;>
> >> Cc: Brandenburg, R. (Ray) van ([email-masked] <javascript:;>);
> Enrico
> >> Marocco; [email-masked] <javascript:;>;
> [email-masked] <javascript:;>; Kevin J
> >> Ma <[email-masked] <javascript:;>> (
> [email-masked] <javascript:;>)
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 2 Aug 2012 03:19:51 +0000

On 1 Aug 2012, at 14:18, Y. Richard Yang wrote:

Hi Francois,

Good suggestion. Jon also mentioned that we might want to reread the use case draft, which contains many use cases already.

Makes sense.

Before we pile in more use cases, I will give a try on the example use case from your email, as the example already touches on some basic issues. In particular, to handle the use case,  the uCDN needs the following info from dCDN[1-4]:

- dCDN1 (ISP1)

I do not believe the use case described require that the footprint partition necessarily be mapped into "QoE" levels. Another approach could be to associate with each partition a hint that reflects some topological properties (e.g1 there are on-net caches to serve that partition or not, eg2 the nb of ASes between caches and partition is 0/1/2/3,…..).

As a starting starting straw-man, I define:
propagation-delay bound (ms) [Mandatory]
max-supported-per-ua-streaming rate (Kbps) [M]
delay-jitter [O]

I believe one of the design team decisions is to not try advertise QoS parameters (at least dynamic ones) along the footprint. As mentioned above, I don't think this is called for by the example use cases.
Also, the use case I describe is a starting point, but the design team is probably going to start by defining the (set of) use case(s) they want to focus on. I suggest we start with that definition before jumping into how to support the use case example I brought up.

Cheers

Francois

I feel that there are multiple experts on content delivery metrics and we can define an initial set.

  Set21 of dCDN2 -> QoE21
  Set22 of dCDN2 -> QoE22
  ...

...

Continue this example, an architecture/protocol issue we may face, while the content delivery metrics group is working on the metrics, is how the uCDN will aggregate the reported QoEs to propagate further. One way is the BGP Best-Path design (applying filtering such as comparison with internal/3rd party measurements) which essential reports a single QoE for each IP. Another design is exposing multipaths by exposing multiple access points. Clearly I support the multipaths design.

Richard

PS: I may suggest the failure/maintainence use case in the use-case draft as a next case. As I see an RSVP style protocol flow will come out of it. I also feel that the affiliation/migration use cases provide another type of distinct use case (less privacy concern).

I hope that helps

Francois

On 31 Jul 2012, at 18:05, Jan Seedorf wrote:

>> From: [email-masked]<javascript:;> [mailto:cdni-footprint-<javascript:;>
>> [email-masked]<javascript:;>] On Behalf Of Jan Seedorf
>> To: [email-masked]<javascript:;>
>> Cc: Brandenburg, R. (Ray) van ([email-masked]<javascript:;>); Enrico
>> Marocco; [email-masked]<javascript:;>; [email-masked]<javascript:;>; Kevin J
>> Ma <[email-masked]<javascript:;>> ([email-masked]<javascript:;>)
> [email-masked]<javascript:;>

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 2 Aug 2012 13:37:38 +0800

Hi Francois,

On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote:

>  Before we pile in more use cases, I will give a try on the example use
> case from your email, as the example already touches on some basic issues.
> In particular, to handle the use case,  the uCDN needs the following info
> from dCDN[1-4]:
>
>  - dCDN1 (ISP1)
>
> I do not believe the use case described require that the footprint
> partition necessarily be mapped into "QoE" levels.
>
Another approach could be to associate with each partition a hint that
> reflects some topological properties (e.g1 there are on-net caches to serve
> that partition or not, eg2 the nb of ASes between caches and partition is
> 0/1/2/3,…..).
>

It appears that I have a different belief :-) The use case is that dCDN1
cannot serve a partition well. Then I prefer that our protocol should say
so (i.e., cannot serve well, i.e., not good quality of service), instead of
using a (potentially positively) correlated property. What do you think?

>  I believe one of the design team decisions is to not try advertise QoS
> parameters (at least dynamic ones) along the footprint.
>

The example metrics I used are stable metrics. Maybe you were reading
jitter? I marked it as optional. I agree that we start with more stable
metrics.

> As mentioned above, I don't think this is called for by the example use
> cases.
> Also, the use case I describe is a starting point, but the design team is
> probably going to start by defining the (set of) use case(s) they want to
> focus on. I suggest we start with that definition before jumping into how
> to support the use case example I brought up.
>

I guess I was eager to solve the first use case that you propose because it
is a good use case...

Thanks!

Richard

> each IP. Another design is exposing multipaths by exposing multiple
> access points. Clearly I support the multipaths design.
>
>  Richard
>
>  PS: I may suggest the failure/maintainence use case in the use-case
> draft as a next case. As I see an RSVP style protocol flow will come out of
> it. I also feel that the affiliation/migration use cases provide another
> type of distinct use case (less privacy concern).
>
> >> really makes sense to have t
>
> [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>

---

From: Scott Wainner <[email-masked]>
Date: Thu, 02 Aug 2012 08:22:43 -0400

It will be difficult to make progress unless we can define explicit 
attributes that refer to footprint and capabilities.  There seems to be 
some agreement that the advertised footprint / capabilities should be 
attributes that are generally time-invariant.

With regard to footprint, I think we can define this in two context:

1) Topologically Dependent
     In this context, we might indicate that a dCDN either has a 
delivery node in an AS or it does not.   A simple binary 
representation.  Of course, an AS can cover any size of geography 
including the globe, so we can make no assumptions about the 
geographical location of any given delivery node.  Nevertheless, a uCDN 
can assess the topological proximity of a dCDN's delivery node based on 
AS-PATH attributes.

2) Topologically Independent
     In this context, we indicate that a dCDN either has a delivery node 
in a geographic location or it does not.  The problem we have with 
geographic location is the scope [city, country, continent] and its 
interpretation.  The dCDN could imply that its delivery node can "reach" 
any of the geographic locations which is somewhat vague.  A single 
delivery node on the Internet can "reach" all geographic locations.  In 
contrast, the definition of a delivery node in a geographic location is 
generally time-invariant.  Either the dCDN has a node installed in the 
location or it does not. Note the availability of a given node may 
change over time. Perhaps this is best addressed outside of the 
time-invariant footprint / capabilities advertisement.  Define the 
granularity of geographic footprint.

Now a uCDN can use the concatenation of the two footprint context to 
discern the 'best' dCDN to use.

Example:  uCDN learns that the client IP is in city_X attached to AS_1

    dCDN_1:  delivery nodes in AS_1
    dCDN_2:  delivery nodes in city_X, city_Y
    dCDN_3:  delivery nodes in AS_2/city_Z

Now which one is best?  Did you choose wisely?  The answer is dCDN3.  
How is this possible?
      dCDN_1 is a global AS with a all their delivery nodes 4,000 miles 
away.
      dCDN_2 is a local ISP which is in the same city, but is 4 AS hops 
away.
      dCDN_3 is a global AS one hop from AS_1 with delivery nodes in 
city_Z which is 30km from city_X

The uCDN is able to use the context of topologically dependent (AS_PATH) 
and topologically independent information (GEOGRAPHIC LOCATION) to find 
the optimal dCDN choice.  Note we haven't even considered capabilities yet.

I'm inclined to define capabilities with time-invariant dCDN attributes 
such as the following:

     HTTP_PDL: Yes or No
     HLS: Yes or No
     HSS: Yes or No
     URL Signing Method A: Yes or No
     URL Signing Mehtod B: Yes or No

The advertised capabilities would certainly be the first set of 
characteristics that the uCDN would use to even qualify a dCDN for 
evaluation in the footprint assessment.  If the uCDN knows that HLS is 
required and the dCDN_3 above is incapable of HLS, then it doesn't 
matter what footprint dCDN_3 covers.  It is not a candidate.  So do we 
have a set of candidate capabilities that can be reflected in a concise 
and unambiguous manner?

Finally, the routing-request logic would be used for time-variant 
attributes.  Perhaps this is where the aspect of performance applies for 
a node in a given footprint / capabilities construct and this could be 
answered by a dCDN with a yes or no.  The dCDN advertised that it could 
serve city_X from AS_2 with HLS and URL Signing Method A.  Now the uCDN 
has a live client request and has called upon the dCDN to execute on 
that advertised capability.  Is the dCDN still capable of serving the 
request at this specific time (i.e. sufficient bandwidth, sufficient 
disk space, sufficient priority, etc.)?

Scott

On 8/2/12 1:37 AM, Y. Richard Yang wrote:
>>     Good suggestion. Jon also mentioned that we might want to reread
>>     the use case draft, which contains many use cases already.
>
>     Makes sense.
>
>>
>>     Before we pile in more use cases, I will give a try on the
>>     example use case from your email, as the example already touches
>>     on some basic issues. In particular, to handle the use case,  the
>>     uCDN needs the following info from dCDN[1-4]:
>>
>>     - dCDN1 (ISP1)
>>
>     Another approach could be to associate with each partition a hint
>     that reflects some topological properties (e.g1 there are on-net
>     caches to serve that partition or not, eg2 the nb of ASes between
>     caches and partition is 0/1/2/3,.....).
>
>
> It appears that I have a different belief :-) The use case is that 
> dCDN1 cannot serve a partition well. Then I prefer that our protocol 
> should say so (i.e., cannot serve well, i.e., not good quality of 
> service), instead of using a (potentially positively) correlated 
> property. What do you think?
>
>
>     I believe one of the design team decisions is to not try advertise
>     QoS parameters (at least dynamic ones) along the footprint.
>
>
> jitter? I marked it as optional. I agree that we start with more 
> stable metrics.
>
>     As mentioned above, I don't think this is called for by the
>     example use cases.
>     Also, the use case I describe is a starting point, but the design
>     team is probably going to start by defining the (set of) use
>     case(s) they want to focus on. I suggest we start with that
>     definition before jumping into how to support the use case example
>     I brought up.
>
>
> I guess I was eager to solve the first use case that you propose 
> because it is a good use case...
>
> Thanks!
>
> Richard
>
>
>     Cheers
>
>     Francois
>
>>
>>     I feel that there are multiple experts on content delivery
>>     metrics and we can define an initial set.
>>
>>     Continue this example, an architecture/protocol issue we may
>>     face, while the content delivery metrics group is working on the
>>     metrics, is how the uCDN will aggregate the reported QoEs to
>>     propagate further. One way is the BGP Best-Path design (applying
>>     filtering such as comparison with internal/3rd party
>>     measurements) which essential reports a single QoE for each IP.
>>     Another design is exposing multipaths by exposing multiple access
>>     PS: I may suggest the failure/maintainence use case in the
>>     use-case draft as a next case. As I see an RSVP style protocol
>>     flow will come out of it. I also feel that the
>>     affiliation/migration use cases provide another type of distinct
>>     use case (less privacy concern).
>>
>>                 1) identify one, or a very small number, of use
>>         case(s) that we want the CDNI Footprint/Capabilities to support
>>
>>         While this approach may arguably not allow us to define the
>>         most flexible universal solution, it would have the merit of
>>         allowing us to define a solution addressing some part of the
>>         problem.
>>
>>         With respect to 1), I think the design team has already
>>         identified ISP CDNs and global CDNs as targeted dCDNs. So
>>         perhaps the use cases of focus could include something like:
>>                 * the uCDN wants to use dCDN1 (CDN of ISP1) when the
>>         enduser is attached to a part of ISP1 and where ISP1 feels
>>         the request can be well served by on-net caches of ISP1 (an
>>         interesting flavor of this is where ISP1 has some of his AS
>>         not covered well by his own CDN - e.g. some remote territory)
>>                 * the uCDN wants to use dCDN2 (CDN of ISP 2) when the
>>         enduser is attached to a part of ISP1 where ISP1 feels the
>>         request can _not_ be well served by on-net caches of ISP1 but
>>         where ISP2 claims that the request can be well served by CDN
>>         of ISP2 (because he has caches that - while not "on-net" on
>>         ISP1 - are well connected to ISP1 e.g. via many regional
>>         peering points)
>>                 * the uCDN wants to use dCDN3 (a global CDN) when the
>>         enduser is attached to any other ISP network with whom dCDN3
>>         is well interconnected (e.g. via many regional peering points)
>>                 * the uCDN wants to use dCDN 4 (another global CDN)
>>         when the enduser is attached to an ISP network with whom
>>         dCDN3 is not well interconnected (e.g. via single centralized
>>         peering points)
>>         I just made that up so it needs more thinking, but take is as
>>         an example of the sort of use case we may want to start from.
>>
>>         I hope that helps
>>
>>         Francois
>>
>>         > Several people have indicated that they will come to this
>>         meeting, so: "it's on" :) Let's meet tomorrow (WED) at 15:00
>>         at the IETF registration desk to continue our discussions,
>>         trying to make some progress ...
>>         >
>>         > - Jan
>>         >