Subject: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities Advertisement

From: Jan Seedorf <[email-masked]>
Date: Tue, 6 Mar 2012 16:09:57 +0000

CDNI Folks,

As discussed in Taipei, we have submitted a draft that tries to define the semantics for the "Footprint and Capabilities Advertisement" part of CDNI Request Routing, see http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00. In Taipei, Martin had agreed to put effort into this (and indeed he started the draft, thanks!), but since he is currently busy with other tasks, I have contributed some text together with Jon and Stefano. Currently, the draft has a lot of open issues and questions, which is probably a good thing to get discussions going.

Abstract:
This document tries to capture the semantics of the "Footprint and Capabilities Advertisment" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisment" is expected to offer within CDNI.  The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisment" within CDNI Request Routing.

If you can think of any other key questions/issues you think need to be discussed (which are not contained in the draft yet), please let us know; we can add them in a future version and will try to remember them for the discussion in Paris.

Looking forward to comments and discussions,

 - Jan

---

From: Scott Wainner <[email-masked]>
Date: Mon, 19 Mar 2012 14:44:21 -0400

Jan,

     Comments on the draft:
     draft-spp-cdni-rr-foot-cap-semantics-00

Section 4: Bullet 1:  Footprint could be defined by ... similar boundary

     I think this is where we get into trouble because the definition of 
a boundary is arbitrary.  Clearly, IP addresses are not arbitrary; 
however, the address ranges may be assigned, partitioned, re-allocated, 
and distributed.  If a portion of a prefix is allocated and distributed 
downstream, then it may extend beyond the definition of the 'boundary'.

     At a macro level, it is easy to map a set of prefixes to an AS 
which has a well defined 'boundary' of peering points.  The caches and 
client are either in the same AS or they are not.  What is interesting 
is the fact that a client and cache in the same AS may not provide the 
'best' path.  The client in AS 1 may leverage a peering point to AS 2 
where the cache of AS-2 is closer than the cache of AS-1.

     In contrast, the use of a geographic 'boundary' such as a city may 
also create a problem.  A client in AS-1 may be in close proximity to a 
cache in AS-2 as defined by the geographic boundary - the same city; 
however, the network topology affords no peering between the two AS 
anywhere close to that defined 'boundary'.

     I'm inclined to say that a 'boundary' must be confined to a portion 
of an AS (which represents a contiguous network infrastructure).  The 
semantics of the 'boundary' must be agreed upon between the dCDN and 
uCDN.  By using an abstract representation of a 'boundary' the two 
parties can agree upon the scope.  The 'boundary' could be defined as a 
particular location, city, province, or country.  Given the uCDN is 
making a decision between itself and various dCDN, the uCDN can weight 
the routing accordingly.  The relationship between uCDN-dCDN1 and 
uCDN-dCDN2 might have different weights.

Section 4: Bullet 2:  Footprint could be defined as the set of the IP 
addresses ...

     I think this is problematic as the dCDN may be changing these 
addresses and may not want to expose exactly how many caches are used.

Section 4: Bullet 4:  Footprint could alternatively be defined as "a 
class of end user requests" ...

     I associate that 'class' label to mean a type of delivery service 
or type of environment that does not necessarily define a footprint.  
I'm inclined to say that "a class of end user requests" might be more 
representative of a CDN capability.  While the footprint is still 
relevant.  In most cases, a dCDN will want to make all their caches 
capable of streaming all for all services at all locations; however, 
that may not be the case.  I'm inclined to associate a 'capability' to a 
footprint boundary.  While we might have an aggregate capability (eg. 
dCDN can deliver HSS), we may have filtered set where some defined 
'boundary' portion of the dCDN is not capable of delivering a particular 
class of traffic.  So now we're starting to correlate capabilities to 
footprint.  I think these generalized capabilities might have a slow 
rate of change.

Section 5: Bullet 1:  Capabilities are types of information ...

     I would define this as the aggregate capability.  There is likely a 
'per boundary' capability which the uCDN may also assess.  This 
granularity (capability per boundary) should be allowed by the protocol 
while use of this granularity should be optional.

     If we use the query model you defined previously, the uCDN might 
see that the dCDN has an aggregate capability to delivery a type of 
service; therefore, it inquires of the dCDN the option to use the dCDN's 
services.  The uCDN might include in the query the 'conditions' upon 
which the dCDN should respond (e.g. 'request for this capability in this 
boundary').  The dCDN may reject the request in the query model or 
accept it.

     If we use the notify model you defined previously, the dCDN might 
have to indicate there are exceptions to the aggregate capability where 
certain 'boundaries' are included in the aggregate or excluded from the 
aggregate.

Section 5: Bullet 2:  Some capabilities may change dynamically ...

     I'm inclined to keep the use of the notify model to a minimum.  The 
uCDN would need only sufficient knowledge to know that the dCDN USUALLY 
has a capability for a given boundary.  State transient delivery 
capabilities within the boundary would be handled at the time of query.

Section 6: Bullet 1:

     a) dCDN push general capabilities for 'boundaries' and persistent 
exceptions to capabilities
     b) uCDN query for current state of capabilities given previous 
statement of dCDN general capabilities
     Ex. dCDN says it can service HSS and HLS for a given boundary;
         uCDN may query dCDN for current state of capabilities for a 
given session setup

Section 6: Bullet 2:

     I'm inclined to go with an abstract 'boundary'.
     It is incumbent upon the uCDN to define the 'boundary'
     It is incumbent upon the dCDN to indicate the capabilities 
according to the defined boundary

     Boundary could be prefix_range, AS, city, country;
     I do think AS's make a good candidate for aggregate boundaries
     I think BGP Extended Communities make good good candidates for 
'specific boundaries'
     The uCDN and dCDN can agree that a BGP Extended Community will 
represent a site, city, or country

Section 6: Bullet 3:

     I'm inclined to have the dCDN advertise static capabilities
     I'm inclined to have the uCDN query about dynamic state of those 
capabilities as needed

Section 6: Bullet 4:

     Use abstract representation of 'costs' by means of unit weight
     The uCDN and dCDN can negotiate the value of unit weights

Section 6: Bullet 5:

     I think monetary delivery costs should not be included.  Units 
should be used (streams, packets, GB, PPS)

Section 6: Bullet 6:

     I think this is the 'cascaded' dCDN.  I think the 'footprint' of 
the tier3 dCDN would have to be represented in a manner that the tier2 
dCDN could aggregate and represent to the uCDN.  The uCDN shouldn't know 
about the details of the tier3 dCDN.  Eg. tier3 dCDN supports 
country_x/city_1 and country_x/city_2.  Tier2 dCDN supports country_y 
and country_x.  uCDN (Tier1) knows that country_x and country_y have 
coverage via the Tier2 dCDN.

Jan, good questions that need to be answered ...

Scott

On 3/6/12 11:09 AM, Jan Seedorf wrote:
>
> CDNI Folks,
>
> As discussed in Taipei, we have submitted a draft that tries to define 
> the semantics for the "Footprint and Capabilities Advertisement" part 
> of CDNI Request Routing, see 
> http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00. In 
> Taipei, Martin had agreed to put effort into this (and indeed he 
> started the draft, thanks!), but since he is currently busy with other 
> tasks, I have contributed some text together with Jon and Stefano. 
> Currently, the draft has a lot of open issues and questions, which is 
> probably a good thing to get discussions going.
>
> Abstract:
> This document tries to capture the semantics of the "Footprint and 
> Capabilities Advertisment" part of the CDNI Request Routing interface, 
> i.e. the desired meaning and what "Footprint and Capabilities 
> Advertisment" is expected to offer within CDNI.  The discussion in 
> this document has the goal to facilitate the choosing of one or more 
> suitable protocols for "Footprint and Capabilities Advertisment" 
> within CDNI Request Routing.
>
> If you can think of any other key questions/issues you think need to 
> be discussed (which are not contained in the draft yet), please let us 
> know; we can add them in a future version and will try to remember 
> them for the discussion in Paris.
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Jan Seedorf <[email-masked]>
Date: Wed, 21 Mar 2012 16:46:19 +0000

Hi Xiaoyan,

Thanks for your input, those are the opinions from the WG we are looking for and would like to have discussed. See my answers inline:

> -Section 1 Introduction assumption "Footprint advertisement and capability
> advertisement need not use the same underlying protocol."
> If capability needs to be associated with a footprint like what is described
> in section 5 of this draft "The dCDN must be able to express particular
> capabilities for the delivery in a particular footprint area." , then the
> easiest way is to advertise the capability and footprint through one same
> message of a protocol.
This might be true, and you provide an argument for having both exchanged with one protocol. But the point here is that - for now, at least - we should not limit ourselves to the assumption that one protocol must be found that does both. It might turn out that protocol A is very suitable for footprint advertisement, but B is much better for capabilities advertisement.

> -3.3 Advertisement versus Queries.
> Does the concept of this section mean that a uCDN does not store any
> capability information of dCDNs in advance, once it receives a routing
> request, it queries capabilities of all dCDNs, if there are multiple dCDNs,
> the uCDN needs to query all of them and wait for responses from all of them
> eventually before making the final decision?  Moreover,  it will take more
> time if one dCDN has its own dCDNs further?   To not compromise end user's
> experience in much advertisement looks better from this perspective.
Good point with the timing. I agree that one disadvantage of the "query on each request" model is that it introduces an additional RTT to the overall service request. One advantage would be - as written in the section - that the dCDN might use more information (that it does not want to disclose or that is changing dynamically) for answering a request when it is queried than it would provide through advertisement. The whole point of the section is that we need to discuss which model we are implicitly assuming.

 - Jan

> -----Original Message-----
> From: HeXiaoyan [mailto:[email-masked]]
> Sent: Monday, March 12, 2012 8:21 AM
> To: Jan Seedorf; [email-masked]
> Subject: RE: [CDNi] New draft on Semantics for CDNI Request Routing -
> Footprint and Capabilities Advertisement
> 
> Hi Jan,
> Although not having certain answers for most of the listed questions and
> looking forward to the working group discussion on them, I'd like to put my
> two cents on this draft here.
> 
> -Section 1 Introduction assumption "Footprint advertisement and capability
> advertisement need not use the same underlying protocol."
> If capability needs to be associated with a footprint like what is described
> in section 5 of this draft "The dCDN must be able to express particular
> capabilities for the delivery in a particular footprint area." , then the
> easiest way is to advertise the capability and footprint through one same
> message of a protocol.
> 
> 
> -3.3 Advertisement versus Queries.
> Does the concept of this section mean that a uCDN does not store any
> capability information of dCDNs in advance, once it receives a routing
> request, it queries capabilities of all dCDNs, if there are multiple dCDNs,
> the uCDN needs to query all of them and wait for responses from all of them
> eventually before making the final decision?  Moreover,  it will take more
> time if one dCDN has its own dCDNs further?   To not compromise end user's
> experience in much advertisement looks better from this perspective.
> 
> 
> Best Regards
> Xiaoyan(Susan) He
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jan
> > Seedorf
> > Sent: Wednesday, March 07, 2012 12:10 AM
> > To: [email-masked]
> > Subject: [CDNi] New draft on Semantics for CDNI Request Routing -
> Footprint
> > and Capabilities Advertisement
> >
> > CDNI Folks,
> >
> > As discussed in Taipei, we have submitted a draft that tries to define the
> > semantics for the "Footprint and Capabilities Advertisement" part of CDNI
> > Request Routing, see
> Taipei,
> > Martin had agreed to put effort into this (and indeed he started the
> draft,
> > thanks!), but since he is currently busy with other tasks, I have
> contributed
> > some text together with Jon and Stefano. Currently, the draft has a lot of
> open
> > issues and questions, which is probably a good thing to get discussions
> going.
> >
> > Abstract:
> Capabilities
> > Advertisment" part of the CDNI Request Routing interface, i.e. the desired
> > meaning and what "Footprint and Capabilities Advertisment" is expected to
> > offer within CDNI.  The discussion in this document has the goal to
> facilitate
> > the choosing of one or more suitable protocols for "Footprint and
> Capabilities
> > Advertisment" within CDNI Request Routing.
> >
> > If you can think of any other key questions/issues you think need to be
> > discussed (which are not contained in the draft yet), please let us know;
> we can
> > add them in a future version and will try to remember them for the
> discussion
> > in Paris.
> >

---

From: Scott Wainner <[email-masked]>
Date: Wed, 21 Mar 2012 14:05:49 -0400

Hybrid approach seems appropriate to me.

dCDN advertises static aggregate capabilities and footprint to uCDN
uCDN can use dCDN static info to choose among many candidate CDN 
(prioritized)
uCDN can query chosen dCDN for current capabilities / footprint

If the dCDN capabilities / footprint haven't changed, then the query 
would likely succeed.

If the dCDN capabilities / footprint have temporarily changed, then the 
uCDN can query the next prioritized dCDN

Scott

On 3/21/12 12:46 PM, Jan Seedorf wrote:
>
> Hi Xiaoyan,
>
> Thanks for your input, those are the opinions from the WG we are 
> looking for and would like to have discussed. See my answers inline:
>
> This might be true, and you provide an argument for having both 
> exchanged with one protocol. But the point here is that - for now, at 
> least - we should not limit ourselves to the assumption that one 
> protocol must be found that does both. It might turn out that protocol 
> A is very suitable for footprint advertisement, but B is much better 
> for capabilities advertisement.
>
> Good point with the timing. I agree that one disadvantage of the 
> "query on each request" model is that it introduces an additional RTT 
> to the overall service request. One advantage would be - as written in 
> the section - that the dCDN might use more information (that it does 
> not want to disclose or that is changing dynamically) for answering a 
> request when it is queried than it would provide through 
> advertisement. The whole point of the section is that we need to 
> discuss which model we are implicitly assuming.
>
>  - Jan
>

---

From: Jan Seedorf <[email-masked]>
Date: Thu, 22 Mar 2012 12:38:46 +0000

Good point, the approaches are not necessarily mutually exclusive. For a hybrid model you describe below "static aggregate capabilities and footprint" might actually have a slightly different semantic than the more dynamic / current footprint & capabilities that a uCDN would query for. So it is probably important to distinguish the two cases; in the end, for the hybrid case different protocols could turn out appropriate for different parts of such a hybrid model.

 - Jan

> Scott Wainner
> Sent: Wednesday, March 21, 2012 7:06 PM
> To: [email-masked]
> Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing -
> If the dCDN capabilities / footprint haven't changed, then the query would
> likely succeed.
> 
> If the dCDN capabilities / footprint have temporarily changed, then the uCDN
> can query the next prioritized dCDN
> 
> Scott
> 
> exchanged with one protocol. But the point here is that - for now, at least -
> we should not limit ourselves to the assumption that one protocol must be
> found that does both. It might turn out that protocol A is very suitable for
> footprint advertisement, but B is much better for capabilities advertisement.
> 
> "query on each request" model is that it introduces an additional RTT to the
> overall service request. One advantage would be - as written in the section -
> that the dCDN might use more information (that it does not want to disclose
> or that is changing dynamically) for answering a request when it is queried
> than it would provide through advertisement. The whole point of the section
> is that we need to discuss which model we are implicitly assuming.
> 
> 	 - Jan
>

---

From: Jan Seedorf <[email-masked]>
Date: Thu, 22 Mar 2012 13:15:32 +0000

Hi Scott,

Thanks for reading the draft and your detailed comments/views on the issues. This is exactly the discussion we need to have. Let me comment only to a few parts of your mail (where I want to add something) below:

> Section 4: Bullet 2:  Footprint could be defined as the set of the IP addresses
> ...
> 
>     I think this is problematic as the dCDN may be changing these addresses
> and may not want to expose exactly how many caches are used.
In my understanding, the IP-addresses would relate to what kind of end user requests the dCDN could serve, and not disclose the location of its caches.

>     It is incumbent upon the uCDN to define the 'boundary'
Do you mean the uCDN should specify the boundary type (e.g. AS # vd. IP-prefix)? I think the boundary itself, i.e. what IP-prefix a dCDN can serve, can only be defines by the dCDN, not?

>     I do think AS's make a good candidate for aggregate boundaries
What about a situation where an ISP has a very large AS in which multiple CDNs are deployed, each of these CDNs not covering the whole AS?

 - Jan

>     I think this is where we get into trouble because the definition of a
> boundary is arbitrary.  Clearly, IP addresses are not arbitrary; however, the
> address ranges may be assigned, partitioned, re-allocated, and distributed.  If
> a portion of a prefix is allocated and distributed downstream, then it may
> extend beyond the definition of the 'boundary'.
> 
>     At a macro level, it is easy to map a set of prefixes to an AS which has a well
> defined 'boundary' of peering points.  The caches and client are either in the
> same AS or they are not.  What is interesting is the fact that a client and cache
> in the same AS may not provide the 'best' path.  The client in AS 1 may
> leverage a peering point to AS 2 where the cache of AS-2 is closer than the
> cache of AS-1.
> 
>     In contrast, the use of a geographic 'boundary' such as a city may also
> create a problem.  A client in AS-1 may be in close proximity to a cache in AS-2
> as defined by the geographic boundary - the same city; however, the
> network topology affords no peering between the two AS anywhere close to
> that defined 'boundary'.
> 
>     I'm inclined to say that a 'boundary' must be confined to a portion of an AS
> (which represents a contiguous network infrastructure).  The semantics of
> the 'boundary' must be agreed upon between the dCDN and uCDN.  By using
> an abstract representation of a 'boundary' the two parties can agree upon
> the scope.  The 'boundary' could be defined as a particular location, city,
> province, or country.  Given the uCDN is making a decision between itself
> and various dCDN, the uCDN can weight the routing accordingly.  The
> relationship between uCDN-dCDN1 and uCDN-dCDN2 might have different
> weights.
> 
> Section 4: Bullet 2:  Footprint could be defined as the set of the IP addresses
> ...
> 
>     I think this is problematic as the dCDN may be changing these addresses
> and may not want to expose exactly how many caches are used.
> 
> Section 4: Bullet 4:  Footprint could alternatively be defined as "a class of end
> user requests" ...
> 
>     I associate that 'class' label to mean a type of delivery service or type of
> environment that does not necessarily define a footprint.  I'm inclined to say
> that "a class of end user requests" might be more representative of a CDN
> capability.  While the footprint is still relevant.  In most cases, a dCDN will
> want to make all their caches capable of streaming all for all services at all
> locations; however, that may not be the case.  I'm inclined to associate a
> 'capability' to a footprint boundary.  While we might have an aggregate
> capability (eg. dCDN can deliver HSS), we may have filtered set where some
> defined 'boundary' portion of the dCDN is not capable of delivering a
> particular class of traffic.  So now we're starting to correlate capabilities to
> footprint.  I think these generalized capabilities might have a slow rate of
> change.
> 
>     I would define this as the aggregate capability.  There is likely a 'per
> boundary' capability which the uCDN may also assess.  This granularity
> (capability per boundary) should be allowed by the protocol while use of this
> granularity should be optional.
> 
>     If we use the query model you defined previously, the uCDN might see
> that the dCDN has an aggregate capability to delivery a type of service;
> therefore, it inquires of the dCDN the option to use the dCDN's services.  The
> uCDN might include in the query the 'conditions' upon which the dCDN
> should respond (e.g. 'request for this capability in this boundary').  The dCDN
> may reject the request in the query model or accept it.
> 
>     If we use the notify model you defined previously, the dCDN might have to
> indicate there are exceptions to the aggregate capability where certain
> 'boundaries' are included in the aggregate or excluded from the aggregate.
> 
>     I'm inclined to keep the use of the notify model to a minimum.  The uCDN
> would need only sufficient knowledge to know that the dCDN USUALLY has a
> capability for a given boundary.  State transient delivery capabilities within
> the boundary would be handled at the time of query.
> 
> Section 6: Bullet 1:
> 
>     b) uCDN query for current state of capabilities given previous statement of
> dCDN general capabilities
>         uCDN may query dCDN for current state of capabilities for a given session
> setup
> 
> Section 6: Bullet 2:
> 
>     It is incumbent upon the dCDN to indicate the capabilities according to the
> defined boundary
> 
>     I think monetary delivery costs should not be included.  Units should be
> used (streams, packets, GB, PPS)
> 
> Section 6: Bullet 6:
> 
>     I think this is the 'cascaded' dCDN.  I think the 'footprint' of the tier3 dCDN
> would have to be represented in a manner that the tier2 dCDN could
> aggregate and represent to the uCDN.  The uCDN shouldn't know about the
> details of the tier3 dCDN.  Eg. tier3 dCDN supports country_x/city_1 and
> country_x/city_2.  Tier2 dCDN supports country_y and country_x.  uCDN
> (Tier1) knows that country_x and country_y have coverage via the Tier2
> dCDN.
> 
> the semantics for the "Footprint and Capabilities Advertisement" part of
> CDNI Request Routing, see http://tools.ietf.org/html/draft-spp-cdni-rr-foot-
> cap-semantics-00. In Taipei, Martin had agreed to put effort into this (and
> indeed he started the draft, thanks!), but since he is currently busy with
> other tasks, I have contributed some text together with Jon and Stefano.
> Currently, the draft has a lot of open issues and questions, which is probably
> a good thing to get discussions going.
> 
> 	Abstract:
> Capabilities Advertisment" part of the CDNI Request Routing interface, i.e.
> the desired meaning and what "Footprint and Capabilities Advertisment" is
> expected to offer within CDNI.  The discussion in this document has the goal
> to facilitate the choosing of one or more suitable protocols for "Footprint and
> Capabilities Advertisment" within CDNI Request Routing.
> 
> be discussed (which are not contained in the draft yet), please let us know;
> we can add them in a future version and will try to remember them for the
> discussion in Paris.
>

---

From: Jan Seedorf <[email-masked]>
Date: Thu, 22 Mar 2012 13:29:12 +0000

Correction:

> addresses
> In my understanding, the IP-addresses would relate to what kind of end user
> requests the dCDN could serve, and not disclose the location of its caches.
I just read again the full text of that bullet and it indeed talks about "IP addresses of the caches deployed by a CDN". That is indeed most likely not in scope for the initial CDNI work, as also pointed out by Francois.

 - Jan

> Jan Seedorf
> Sent: Thursday, March 22, 2012 2:16 PM
> To: Scott Wainner; [email-masked]
> Thanks for reading the draft and your detailed comments/views on the
> issues. This is exactly the discussion we need to have. Let me comment only
> to a few parts of your mail (where I want to add something) below:
> 
> addresses
> In my understanding, the IP-addresses would relate to what kind of end user
> requests the dCDN could serve, and not disclose the location of its caches.
> 
> > Section 6: Bullet 2:
> >
> Do you mean the uCDN should specify the boundary type (e.g. AS # vd. IP-
> prefix)? I think the boundary itself, i.e. what IP-prefix a dCDN can serve, can
> only be defines by the dCDN, not?
> 
> What about a situation where an ISP has a very large AS in which multiple
> CDNs are deployed, each of these CDNs not covering the whole AS?
> 
> 
> 
>  - Jan
> 
> 
> 
> 
> addresses