Subject: [CDNi] FW: New Version Notification for draft-he-cdni-cap-info-advertising-00.txt

From: HeXiaoyan <[email-masked]>
Date: Thu, 16 Feb 2012 19:13:06 +0800

Hi all,
We have submitted a draft on capability advertising of CDNI,
 http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/

Your comments are welcome.

Best Regards
Xiaoyan(Susan) He

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 16, 2012 7:10 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-he-cdni-cap-info-advertising-00.txt

A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has been successfully submitted by Xiaoyan He and posted to the IETF repository.

Filename:	 draft-he-cdni-cap-info-advertising
Revision:	 00
Title:		 Capability Information Advertising for CDN Interconnection
Creation date:	 2012-02-16
WG ID:		 Individual Submission
Number of pages: 11

Abstract:
  This document describes protocol for Capability Information Advertising
which is   used to communicate capability information among interconnected Content
Delivery   Networks(CDNs).

The IETF Secretariat

---

From: Scott Wainner <[email-masked]>
Date: Mon, 20 Feb 2012 08:35:35 -0500

Xiaoyan,

Section 3: Capability information description

o Resource status of each downstream

     I don't think we want the be constantly advertising changes in the 
usage percentage and available bandwidth.  The DECISION to allow or not 
allow content acquisition and the threshold upon when that decision is 
made is likely to vary and be subject to the policies of the dCDN (e.g. 
allow 60% load or allow 80% load).  In addition, the decision to acquire 
content (for dynamic acquisition) is made AFTER the decision has been 
made to redirect the client to the dCDN for content delivery.  I'm 
inclined to say the dCDN needs to indicate to the uCDN that it should or 
should not redirect clients to the dCDN and that decision is based on 
internal characteristics of the dCDN (cache-miss rates, circuit loads, 
acquisition capacities, etc.).  This probably needs to be a binary 
notification for each delivery service defined.

o Footprint of each Downstream CDN

     I think the footprint needs to be defined for each type of delivery 
service.

     I think the capacity argument above needs to be at the granularity 
of the "footprint".  Perhaps we need to define footprint.  Is that a 
continent, country, province, state, region, city.  At a macro level, we 
might indicate that the dCDN can support a delivery service in all the 
European countries, but the resources in a particular country are 
exhausted.  We now have a decision to make.  Should the uCDN continue to 
re-direct clients to the dCDN?  If it does, the costs assigned to the 
dCDN will increase as the client will be assigned a distribution node in 
the closest available location for that service.  On the contrary, the 
dCDN might increase the costs associated with distribution in that one 
country such that the uCDN decides not to re-direct the client.

o Delivery protocol supported by each Downstream CDN;

     I think this is appropriate and should be reflected in a type of 
delivery service.  Example: Microsoft Smooth Streaming is supported in 
the following countries ...; Apple HTTP Live Streaming is supported in 
the following cities ...;  Adobe HTTP Dynamic Streaming is supported on 
the following BGP networks ...

     Clearly, we need to define 'footprint'.

o Cost information of each Downstream CDN;

     How do we characterize costs?  Cost relative to what?  Not sure we 
want to include a currency converter in our protocol.  We might want to 
define cost as an abstract value that can be negotiated between the uCDN 
and dCDN.  That means the dCDN internal cost metrics need to be 
characterized in the abstract cost assignment advertised to the uCDN.  
That cost could be in any currency.  In fact, the cost could be in 
latency or distance.  As long as the two parties agree on how to assess 
cost.

o Authentication type to end user supported by each of the Downstream CDN

     I don't see this as optional.  Each dCDN is likely to expect the 
use some authentication method between the client and the delivery 
node.  That credential may be provided by the service routing function 
or some other system.  The dCDN needs to advertise the method and where 
to obtain the credentials for each type of routing request.  I think the 
uCDN will need to receive a routing request from its own client (using 
its own credentials), ascertain which dCDN the client should be 
redirected, determine the method of authentication (and perhaps obtain 
the credential on behalf of the client), and respond to the client.

5.1 Capability information description

     I'm less inclined to include usage percentages in any reports as 
the dCDN may be servicing other uCDN.  If we're talking about a maximum 
allowed threshold contracted between the uCDN and dCDN, then the usage 
percentage might be relative to that contracted streaming capacity.  Of 
course, percentage can be provided by simply providing the maximum 
contracted streaming capacity and the current streaming assignments in 
different categories:

     Streams Allowed, Streams Assigned
     Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will be 
tough with ABR)
     Cached Assets Allowed, Cached Assets

     I also see in the table you have started defining 'Coverage' which 
may also be described as 'Footprint'.  Probably need to define one term 
and keep it consistent.  We then need to define the 'Coverage' or 
'Footprint' elements.

     Also need to define 'Peak Delivery Capability' or 'Guaranteed 
Minimum Capability' for a given 'Coverage'.  Contractually, some content 
owners expect their uCDN to provide high-quality content delivery 
(high-capacity streaming) and want to insure the delivery networks can 
facilitate that type of support.  If the dCDN has a capped delivery 
capability (either by the delivery node or the access infrastructure), 
the uCDN needs to know that in order to 'qualify' the dCDN for content 
delivery.

Scott Wainner

On 2/16/12 6:13 AM, HeXiaoyan wrote:
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: New Version Notification for 
> draft-he-cdni-cap-info-advertising-00.txt
>
> A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has 
> been successfully submitted by Xiaoyan He and posted to the IETF 
> repository.
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 20 Feb 2012 21:10:38 +0000

Colleagues,

I'd suggest that more work needs to be done on the classes of capability that need to be exchanged as well as specific capabilities that may be useful before worrying too much what the actual protocol may look like.

For example two immediate classes that come to mind are slow changing Vs fast changing capabilities. E.g. I would expect that the version of IP and individual delivery protocols supported would change slowly.

You might also want to think about how to convey non-binary (i.e. on/off) capabilities in a more abstract way as I'm not sure folks will want to expose for e.g. "I can support X more connections" etc.

Ben

On 20 Feb 2012, at 13:35, Scott Wainner wrote:

>     I don't think we want the be constantly advertising changes in the usage percentage and available bandwidth.  The DECISION to allow or not allow content acquisition and the threshold upon when that decision is made is likely to vary and be subject to the policies of the dCDN (e.g. allow 60% load or allow 80% load).  In addition, the decision to acquire content (for dynamic acquisition) is made AFTER the decision has been made to redirect the client to the dCDN for content delivery.  I'm inclined to say the dCDN needs to indicate to the uCDN that it should or should not redirect clients to the dCDN and that decision is based on internal characteristics of the dCDN (cache-miss rates, circuit loads, acquisition capacities, etc.).  This probably needs to be a binary notification for each delivery service defined.
> 
>     I think the footprint needs to be defined for each type of delivery service.  
> 
>     I think the capacity argument above needs to be at the granularity of the "footprint".  Perhaps we need to define footprint.  Is that a continent, country, province, state, region, city.  At a macro level, we might indicate that the dCDN can support a delivery service in all the European countries, but the resources in a particular country are exhausted.  We now have a decision to make.  Should the uCDN continue to re-direct clients to the dCDN?  If it does, the costs assigned to the dCDN will increase as the client will be assigned a distribution node in the closest available location for that service.  On the contrary, the dCDN might increase the costs associated with distribution in that one country such that the uCDN decides not to re-direct the client.
> 
>     I think this is appropriate and should be reflected in a type of delivery service.  Example: Microsoft Smooth Streaming is supported in the following countries ...; Apple HTTP Live Streaming is supported in the following cities ...;  Adobe HTTP Dynamic Streaming is supported on the following BGP networks ...
> 
>     How do we characterize costs?  Cost relative to what?  Not sure we want to include a currency converter in our protocol.  We might want to define cost as an abstract value that can be negotiated between the uCDN and dCDN.  That means the dCDN internal cost metrics need to be characterized in the abstract cost assignment advertised to the uCDN.  That cost could be in any currency.  In fact, the cost could be in latency or distance.  As long as the two parties agree on how to assess cost.
> 
>     I don't see this as optional.  Each dCDN is likely to expect the use some authentication method between the client and the delivery node.  That credential may be provided by the service routing function or some other system.  The dCDN needs to advertise the method and where to obtain the credentials for each type of routing request.  I think the uCDN will need to receive a routing request from its own client (using its own credentials), ascertain which dCDN the client should be redirected, determine the method of authentication (and perhaps obtain the credential on behalf of the client), and respond to the client.
> 
>     I'm less inclined to include usage percentages in any reports as the dCDN may be servicing other uCDN.  If we're talking about a maximum allowed threshold contracted between the uCDN and dCDN, then the usage percentage might be relative to that contracted streaming capacity.  Of course, percentage can be provided by simply providing the maximum contracted streaming capacity and the current streaming assignments in different categories:
> 
>     Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will be tough with ABR)
>     I also see in the table you have started defining 'Coverage' which may also be described as 'Footprint'.  Probably need to define one term and keep it consistent.  We then need to define the 'Coverage' or 'Footprint' elements.
> 
>     Also need to define 'Peak Delivery Capability' or 'Guaranteed Minimum Capability' for a given 'Coverage'.  Contractually, some content owners expect their uCDN to provide high-quality content delivery (high-capacity streaming) and want to insure the delivery networks can facilitate that type of support.  If the dCDN has a capped delivery capability (either by the delivery node or the access infrastructure), the uCDN needs to know that in order to 'qualify' the dCDN for content delivery.
> 
> Scott Wainner
> 
> 
>

---

From: Scott Wainner <[email-masked]>
Date: Mon, 20 Feb 2012 16:25:30 -0500

On 2/20/12 4:10 PM, Ben Niven-Jenkins wrote:
>
> Colleagues,
>
> I'd suggest that more work needs to be done on the classes of 
> capability that need to be exchanged as well as specific capabilities 
> that may be useful before worrying too much what the actual protocol 
> may look like.
>
Agree.
>
>
> For example two immediate classes that come to mind are slow changing 
> Vs fast changing capabilities. E.g. I would expect that the version of 
> IP and individual delivery protocols supported would change slowly.
>
Agree.  There capabilities (allowed protocols, footprint, etc.) that may 
not change for days while the current ability to actually use those 
capabilities could change more frequently.
>
>
> You might also want to think about how to convey non-binary (i.e. 
> on/off) capabilities in a more abstract way as I'm not sure folks will 
> want to expose for e.g. "I can support X more connections" etc.
>
Exactly my point.  We need the uCDN to be given a simple set of go/no-go 
criteria from the dCDN.

Scott Wainner
> >     I don't think we want the be constantly advertising changes in 
> the usage percentage and available bandwidth.  The DECISION to allow 
> or not allow content acquisition and the threshold upon when that 
> decision is made is likely to vary and be subject to the policies of 
> the dCDN (e.g. allow 60% load or allow 80% load).  In addition, the 
> decision to acquire content (for dynamic acquisition) is made AFTER 
> the decision has been made to redirect the client to the dCDN for 
> content delivery.  I'm inclined to say the dCDN needs to indicate to 
> the uCDN that it should or should not redirect clients to the dCDN and 
> that decision is based on internal characteristics of the dCDN 
> (cache-miss rates, circuit loads, acquisition capacities, etc.).  This 
> probably needs to be a binary notification for each delivery service 
> defined.
> >
> >     I think the capacity argument above needs to be at the 
> granularity of the "footprint".  Perhaps we need to define footprint.  
> Is that a continent, country, province, state, region, city.  At a 
> macro level, we might indicate that the dCDN can support a delivery 
> service in all the European countries, but the resources in a 
> particular country are exhausted.  We now have a decision to make.  
> Should the uCDN continue to re-direct clients to the dCDN?  If it 
> does, the costs assigned to the dCDN will increase as the client will 
> be assigned a distribution node in the closest available location for 
> that service.  On the contrary, the dCDN might increase the costs 
> associated with distribution in that one country such that the uCDN 
> decides not to re-direct the client.
> >
> the following cities ...;  Adobe HTTP Dynamic Streaming is supported 
> on the following BGP networks ...
> >
> >     How do we characterize costs?  Cost relative to what?  Not sure 
> we want to include a currency converter in our protocol.  We might 
> want to define cost as an abstract value that can be negotiated 
> between the uCDN and dCDN.  That means the dCDN internal cost metrics 
> need to be characterized in the abstract cost assignment advertised to 
> the uCDN.  That cost could be in any currency.  In fact, the cost 
> could be in latency or distance.  As long as the two parties agree on 
> how to assess cost.
> >
> or some other system.  The dCDN needs to advertise the method and 
> where to obtain the credentials for each type of routing request.  I 
> think the uCDN will need to receive a routing request from its own 
> client (using its own credentials), ascertain which dCDN the client 
> should be redirected, determine the method of authentication (and 
> perhaps obtain the credential on behalf of the client), and respond to 
> the client.
> >
> the dCDN may be servicing other uCDN.  If we're talking about a 
> maximum allowed threshold contracted between the uCDN and dCDN, then 
> the usage percentage might be relative to that contracted streaming 
> capacity.  Of course, percentage can be provided by simply providing 
> the maximum contracted streaming capacity and the current streaming 
> assignments in different categories:
> >
> >     I also see in the table you have started defining 'Coverage' 
> which may also be described as 'Footprint'.  Probably need to define 
> one term and keep it consistent.  We then need to define the 
> 'Coverage' or 'Footprint' elements.
> >
> Minimum Capability' for a given 'Coverage'.  Contractually, some 
> content owners expect their uCDN to provide high-quality content 
> delivery (high-capacity streaming) and want to insure the delivery 
> networks can facilitate that type of support.  If the dCDN has a 
> capped delivery capability (either by the delivery node or the access 
> infrastructure), the uCDN needs to know that in order to 'qualify' the 
> dCDN for content delivery.
> >
> > Scott Wainner
> >
> >
> >
> been           successfully submitted by Xiaoyan He and posted to the 
> IETF repository.
> >>

---

From: HeXiaoyan <[email-masked]>
Date: Tue, 21 Feb 2012 20:38:06 +0800

Scott and Ben,
This draft is a very primary version and the intention of it was to
stimulate the group to discuss capability advertising and thanks for your
comments. I agree with you that there is still a lot need to do to amend it.
As it seems that we still have divergence on what kind of capability info
need to be exchanged, I reconsider the way work on it, here is something
come into mind.
1. First we find and get agreement on the criteria that determine the
capability that needed to be exchanged. We can use these criteria to filter
the capability information and walk a step forward to define the semantics
of each. As the capability info is used to facility request routing, and
uCDNs may have vary internal routing policy, below is some criteria based on
the often mentioned use cases.
 * Make routing decision(selecting a dCDN) based on proximity, hence
footprint category info is needed.
 * Make routing decision based on minimal load, hence resource status
category info of dCDN is needed.   
 *Make routing decision based on capability , hence delivery
protocol/service type, user authentication method category info is needed.
 *Make routing decision based on minimal expense, hence cost category info
is needed.
 *Make routing decision based on optimal QoS, hence performance data is
needed, e.g. latency, distance, Peak Delivery Capability , Guaranteed
Minimum
  Capability.

2. Based on the above categories, evaluate the granularity of each kind of
capability info under the CDNI circumstance, convey the info in a abstract
way as you two suggested or uCDN prefer a more detail one ?Again, should be
thought as semantics definition.

3.Define syntax of the capability info mentioned above. Based on your
comments, here is an example of revision for your comments.
<CapabilityAd>
< IPVersion >IPV4</ IPVersion >
< ServiceStatus>1</ ServiceStatus >
<LoadStatus>  !--aggeragated
<MaxConnection>10000</ MaxConnection >
<UsedConnection>500</ UsedConnection>
<MaxDeliveryBW>20000</ MaxConnection >
<DeliveryBWUsage>5000</ DeliveryBWUsage >
</LoadStatus>
< Coverage>Country=A,State=B,City=C
< Performance >
< Latency > 10ms</ Latency >
</ Performance >
<Capability >
< DeliveryCap > Protocol="HTTP"
<LoadStatus>   !--per delivery protocol
<MaxConnection>2000</ MaxConnection >
<UsedConnection>1000</ UsedConnection >
</LoadStatus>
<Expense>900$/GM</ MaxConnection >
</ DeliveryCap >
< DeliveryCap >Protocol="RTSP/RTP"
..
</ DeliveryCap >
< SecurityCap > Authentication="RSA256"</ Authentication >
</ Capability >
</ Coverage >
< Coverage>Country=D,State=E,City=F
..
< Coverage>
</CapabilityAd> 

4.Define the protocol.

I'll prepare a revision of this draft focusing on above step 1,2 and 3 based
on our discussion , and any other colleagues who would like to
contribute/collaborate are welcome.   

Please see my other responses inline. 

Best Regards
Xiaoyan(Susan) He
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben
> Niven-Jenkins
> Sent: Tuesday, February 21, 2012 5:11 AM
> To: Scott Wainner
> Cc: [email-masked]
> Subject: Re: [CDNi] FW: New Version Notification for
> I'd suggest that more work needs to be done on the classes of capability
that
> need to be exchanged as well as specific capabilities that may be useful
before
> worrying too much what the actual protocol may look like.

[Xiaoyan] Agree. Will do this on the revision. 

> For example two immediate classes that come to mind are slow changing Vs
> fast changing capabilities. E.g. I would expect that the version of IP and
> individual delivery protocols supported would change slowly.
> 
> You might also want to think about how to convey non-binary (i.e. on/off)
> capabilities in a more abstract way as I'm not sure folks will want to
expose for
> e.g. "I can support X more connections" etc.
> 
[Xiaoyan] Will think this in the revision, hope can address it.

> allow content acquisition and the threshold upon when that decision is
made is
> likely to vary and be subject to the policies of the dCDN (e.g. allow 60%
load or
> allow 80% load).  In addition, the decision to acquire content (for
dynamic
> acquisition) is made AFTER the decision has been made to redirect the
client to
> the dCDN for content delivery.  I'm inclined to say the dCDN needs to
indicate
> to the uCDN that it should or should not redirect clients to the dCDN and
that
> decision is based on internal characteristics of the dCDN (cache-miss
rates,
> circuit loads, acquisition capacities, etc.).  This probably needs to be a
binary
> notification for each delivery service defined.

[Xiaoyan] Actually, bandwidth info of the content acquisition had been
removed in the table of section 5.1 for 
Similar reason as you mentioned, I forgot synchronize to update the
description of section3. Regarding the remaining maximum
Delivery bandwidth and delivery bandwidth usage, it is relative to the
contracted value between the two CDNs, i.e. the dCDN has
Committed to provide that value of bandwidth to the uCDN. I think our
divergence is who should make the decision not to go, uCDN based
On its contracted service and its usage status of this service or the dCDN
make this decision and simply sent a binary notification to uCDN(similar 
For the maximum connection and used connection)? I don't have a strong
opinion, and would like to hear other experts' view. 

> >     I think the capacity argument above needs to be at the granularity
of
> the "footprint".  Perhaps we need to define footprint.  Is that a
continent,
> country, province, state, region, city.  At a macro level, we might
indicate that
> the dCDN can support a delivery service in all the European countries, but
the
> resources in a particular country are exhausted.  We now have a decision
to
> make.  Should the uCDN continue to re-direct clients to the dCDN?  If it
does,
> the costs assigned to the dCDN will increase as the client will be
assigned a
> distribution node in the closest available location for that service.  On
the
> contrary, the dCDN might increase the costs associated with distribution
in
> that one country such that the uCDN decides not to re-direct the client.

[Xiaoyan] I think this is relative to the syntax of the capability info, I
can try to
Do this in the revision if other colleagues in the group think this
expression is a good way.

> >     I think this is appropriate and should be reflected in a type of
delivery
> service.  Example: Microsoft Smooth Streaming is supported in the
following
> countries ...; Apple HTTP Live Streaming is supported in the following
cities ...;
> Adobe HTTP Dynamic Streaming is supported on the following BGP networks
...
[Xiaoyan] Same as previous one.

> want to include a currency converter in our protocol.  We might want to
define
> cost as an abstract value that can be negotiated between the uCDN and
dCDN.
> That means the dCDN internal cost metrics need to be characterized in the
> abstract cost assignment advertised to the uCDN.  That cost could be in
any
> currency.  In fact, the cost could be in latency or distance.  As long as
the
> two parties agree on how to assess cost.

[Xiaoyan] In the draft now I recommend we characterize cost based on data
size( per GB) delivered to end user
On behalf the uCDN, this is very straightforward. Could you explain more if
the cost is in an abstract value such as
Latency or distance, how can the uCDN implement the minimal expense policy?
Thanks. 

> >     I don't see this as optional.  Each dCDN is likely to expect the use
some
> authentication method between the client and the delivery node.  That
> credential may be provided by the service routing function or some other
> system.  The dCDN needs to advertise the method and where to obtain the
> credentials for each type of routing request.  I think the uCDN will need
to
> receive a routing request from its own client (using its own credentials),
> ascertain which dCDN the client should be redirected, determine the method
of
> authentication (and perhaps obtain the credential on behalf of the
client), and
> respond to the client.

[Xiaoyan]Don't quite understand what you mean here, could you explain more
on the case you thought about,
what is the purpose of dCDN advertiseWhere to obtain the credential? When I
wrote this what in my mind is for
some contents the CP may require that the CDN it delegate should
authenticate the end user, CP has sent the key to the 
uCDN when they contracted, and uCDN sent it to the dCDN when they
contracted, after the dCDN receive 
a user request for the contents, it will use this key and the authentication
method to authenticate the user against token conveyed in the URL.
As not all contents need this operation, it is recommend as optional.

> >     I'm less inclined to include usage percentages in any reports as the
> dCDN may be servicing other uCDN.  If we're talking about a maximum

[Xiaoyan]Yes, it is about a maximum allowed threshold contracted between the
CDNs. I think this is relative to your first above comment. 
Could you check again which you prefer, the detail value or a simply binary
go/not go notification?

> >     I also see in the table you have started defining 'Coverage' which
may
> also be described as 'Footprint'.  Probably need to define one term and
keep it
> consistent.  We then need to define the 'Coverage' or 'Footprint'
elements.
[Xiaoyan] Agree.

> >     Also need to define 'Peak Delivery Capability' or 'Guaranteed
Minimum
> Capability' for a given 'Coverage'.  Contractually, some content owners
expect
> their uCDN to provide high-quality content delivery (high-capacity
streaming)
> and want to insure the delivery networks can facilitate that type of
support.  If
> the dCDN has a capped delivery capability (either by the delivery node or
the
> access infrastructure), the uCDN needs to know that in order to 'qualify'
the
> dCDN for content delivery.

[Xiaoyan]I think this depend on the way of the delivery bandwidth
advertisement,
If it is a binary notification, then this may be needed to 'qualify' the
content delivery.
If it is the detail maximum contracted delivery bandwidth and the usage
info,
The uCDN can 'qualify' the content delivery through the bandwidth retained. 

> >> A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has
been
> successfully submitted by Xiaoyan He and posted to the IETF repository.
> >>

---

From: Scott Wainner <[email-masked]>
Date: Tue, 21 Feb 2012 09:19:25 -0500

Xiaoyan (Susan) He,

Perhaps we need to delineate between baseline (mandatory) capabilities 
and enhanced (optional) capabilities.  I'm inclined to think that the 
client has communicated with the content owner's portal and chosen an 
asset to view.  At this point, the client capabilities have already 
created a filtered set of assets that are viable for delivery.  The uCDN 
needs to take this initial filter criteria into consideration.  This 
might include capabilities that are baseline requirements:

      1) protocol/service type
      2) authentication method
      3) performance criteria (guaranteed capability)

In this case, the potential set of dCDN either meet the qualification or 
they do not.  From this filtered set of dCDN, we now have the ability to 
assess the remaining set of dCDN based on enhanced requirements:

      1) proximity
      2) load
      3) cost
      4) performance criteria (target capability)

Scott

On 2/21/12 7:38 AM, HeXiaoyan wrote:
> on/off)

---

From: HeXiaoyan <[email-masked]>
Date: Wed, 22 Feb 2012 16:50:46 +0800

Scott,

Inline, thanks.

Best Regards

Xiaoyan(Susan) He

From: Scott Wainner [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2012 10:19 PM
To: HeXiaoyan
Cc: Ben Niven-Jenkins; [email-masked]
Subject: Re: [CDNi] FW: New Version Notification
fordraft-he-cdni-cap-info-advertising-00.txt

Xiaoyan (Susan) He,

Perhaps we need to delineate between baseline (mandatory) capabilities and
enhanced (optional) capabilities.  I'm inclined to think that the client has
communicated with the content owner's portal and chosen an asset to view.
At this point, the client capabilities have already created a filtered set
of assets that are viable for delivery.  The uCDN needs to take this initial
filter criteria into consideration.  This might include capabilities that
are baseline requirements:

     1) protocol/service type
     2) authentication method 
     3) performance criteria (guaranteed capability)
[Xiaoyan] In my understanding,  in the context of CDN/CDNI, these info
finally should be reflected as part of the metadata correlated with the
content.  To 'qualify' the delivery service , CP defines the metadata and
send this metadata to the contracted uCDN,   uCDN send it to contracted
dCDNs as well for same reason.  uCDN then use this metadata to filter the
dCDNs while doing the routing request redirection, to facilitate that, dCDN
needs to advertise capability corresponding to this metadata in advance. As
the metadata interface still has not been settled(what kind of capabilities
included in the CDNI metadata), we cannot  deduce which are baseline
requirements now but can give some and adjust based on metadata interface
later when it is settled down.
In this case, the potential set of dCDN either meet the qualification or
they do not.  From this filtered set of dCDN, we now have the ability to
assess the remaining set of dCDN based on enhanced requirements:

     1) proximity
     2) load
     3) cost
     4) performance criteria (target capability)
[Xiaoyan] These actually  are all information related to the local routing
policy of uCDN, to meet the policy, I don't think they should be kept as
optional.

Scott

Scott and Ben,

4.Define the protocol.

Best Regards
Xiaoyan(Susan) He
Ben
that
before

expose for

made is
load or
dynamic
client to
indicate
that
rates,
binary

of
continent,
indicate that
the
to
does,
assigned a
the
in

delivery
following
cities ...;
...

define
dCDN.
any
the

some
to
of
client), and

may
keep it
elements.
[Xiaoyan] Agree.

Minimum
expect
streaming)
support.  If
the
the

been