Subject: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-00.txt

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 20 Mar 2012 10:22:42 +0100

(As an individual),

In my opinion, the content of the cdni-requirements document can be reflected more accurately and can be leveraged more extensively to start answering some of the questions.

For example:

	* when listing the cdni-requirements requirements, I recommend the HIGH/MED/LOW prioritization be stated, as this is very significant information on the current consensus of what is seen as essential for the initial WG deliverables and what is not	

	* the "summary" of REQ-1 is misleading and needs to be changed. It only quotes communicate "excessive load or failure condition" suggesting the requirement is about exchanging load information, when the requirement is actually about "coarse information about the Downstream CDN ability and/or willingness to handle requests from the Upstream CDN" and when mentioning load as _an example_ it qualifies it as a "binary signal" -aka an aggregate CDN level busy-tone.

	* the requirement related to support of cascaded CDNs must be included as it impacts the overall solution:
"   REQ-3   [MED] In the case of cascaded redirection, the CDNI Request-
           Routing interface shall allow the Downstream CDN to also
           include in the information communicated to the Upstream CDN,
           information on the capabilities, resources and affinities of
           CDNs to which the Downstream CDN may (in turn) redirect
           requests received by the Upstream CDN.  In that case, the
           CDNI Request-Routing interface shall prevent looping of such
           information exchange.
"

	* the generic requirements of cdni-requirements that strongly affect the footprint & capabilities advertisement interface should be included. In particular:
"   GEN-4   [HIGH] The CDNI solution shall not require intra-CDN
           information to be exposed to other CDNs for effective and
           efficient delivery of the content.  Examples of intra-CDN
           information include surrogate topology, surrogate status,
           cached content, etc.
"

In line with GEN-4, I believe the 2nd of the "candidates for definitions of a footprint" listed in section 4 (ie "o  Footprint could be defined as the set of the IP addresses of the caches deployed by a CDN.") can be excluded (at least for initial CDNI WG work).

In line with GEN-4, I believe some of the candidate "capabilities" listed in section 5 (ie  individual "Cache Capabilities are:   o  load, or "excessive load",   o  available resources, storage resources,   o  failure conditions) can be excluded (at least for initial CDNI WG work).

In line with REQ-3, the 3rd bullet of section 4 should not read "Potentially, a footprint may include ..." but something like "A footprint needs to be able to include....". Also, I don't look at this 3rd bullet as an alternative candidate definition to the others: it is a qualifier to the other definitions (ie whatever "footprint is", a given footprint advertised by a CDN need to be able to reflect cascaded CDN footprints in addition to the advertising CDN footprint).  

As per the recent email thread, I believe there is consensus that the CDNI footprint & capabilities advertisement interface is all about helping the uCDN select a dCDN, and not about helping the uCDN to select a specific cache in the dCDN (at least for the initial CDNI WG work). While this is already implicitly reflected in the wording of requirements and description, I would recommend stating this explicitly to avoid confusion.

Regarding the section 1 statement "Footprint advertisement and capability advertisement need not use the same underlying protocol." :
While this is true, it is interesting to consider this in light of the following statement in section 5 "The dCDN must be able to express particular capabilities for the delivery in a particular footprint area." Perhaps, it may be worth expanding the section 5 statement to point out that where capabilities are to be expressed on a per footprint area there _may_ be benefit in combining the footprint and capability advertisements.

Cheers

Francois

On 5 Mar 2012, at 17:03, [email-masked] wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : CDNI Request Routing: Footprint and Capabilities Semantics
> 	Author(s)       : Jan Seedorf
>                          Jon Peterson
>                          Stefano Previdi
> 	Filename        : draft-spp-cdni-rr-foot-cap-semantics-00.txt
> 	Pages           : 17
> 	Date            : 2012-03-05
> 
>   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.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-00.txt
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

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

Hi Francois,

Thanks for reading the draft and your comments. Let me answer inline below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francois Le Faucheur
> Sent: Tuesday, March 20, 2012 10:23 AM
> To: [email-masked]
> Subject: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-
> semantics-00.txt
> 
> (As an individual),
> 
> In my opinion, the content of the cdni-requirements document can be
> reflected more accurately and can be leveraged more extensively to start
> answering some of the questions.
> 
> For example:
> 
> 	* when listing the cdni-requirements requirements, I recommend
> the HIGH/MED/LOW prioritization be stated, as this is very significant
> information on the current consensus of what is seen as essential for the
> initial WG deliverables and what is not
Ok, we will do that in the next revision

> 
> 	* the "summary" of REQ-1 is misleading and needs to be changed. It
> only quotes communicate "excessive load or failure condition" suggesting
> the requirement is about exchanging load information, when the
> requirement is actually about "coarse information about the Downstream
> CDN ability and/or willingness to handle requests from the Upstream CDN"
> and when mentioning load as _an example_ it qualifies it as a "binary signal" -
> aka an aggregate CDN level busy-tone.
Ok, true. The intention for section 2 of our draft was simply to give some examples that have been mentioned in existing documents regarding the term "footprint" and "capability". Probably that was not precise in this case, will update it.

> 
> 	* the requirement related to support of cascaded CDNs must be
> included as it impacts the overall solution:
Not sure about this one. I read the requirement that the overall CDNI request routing needs to support cascaded CDNs, and that information exchanged needs to include cascaded dCDNs. The question at hand is if the "advertisement" part also needs to signal such cascading information EXPLICITLY, or if cascading CDNs merely need to be supported by the redirection part of the request routing interface, i.e. the cascading information is IMPLICITLY included in the advertisement information. This is to me the open question, which we try to raise in the draft. But it is probably a good idea to clarify that a bit more in the draft and to cite the requirement above.

> 
> 	* the generic requirements of cdni-requirements that strongly affect
> the footprint & capabilities advertisement interface should be included. In
> particular:
Ok, good idea. Again, we only looked for example definitions in the reqs document for now, that's why it is not included so far. But you are right that this requirement probably precludes certain capabilities.

> 
> In line with GEN-4, I believe the 2nd of the "candidates for definitions of a
> footprint" listed in section 4 (ie "o  Footprint could be defined as the set of
> the IP addresses of the caches deployed by a CDN.") can be excluded (at
> least for initial CDNI WG work).
Agree, true.

> 
> In line with GEN-4, I believe some of the candidate "capabilities" listed in
> section 5 (ie  individual "Cache Capabilities are:   o  load, or "excessive load",
> o  available resources, storage resources,   o  failure conditions) can be
> excluded (at least for initial CDNI WG work).
Not sure. In my view, the dCDN could in principle express load not for individual caches but for caches in a certain region without disclosing details about its caches.

> 
> In line with REQ-3, the 3rd bullet of section 4 should not read "Potentially, a
> footprint may include ..." but something like "A footprint needs to be able to
> include....". Also, I don't look at this 3rd bullet as an alternative candidate
> definition to the others: it is a qualifier to the other definitions (ie whatever
> "footprint is", a given footprint advertised by a CDN need to be able to
> reflect cascaded CDN footprints in addition to the advertising CDN footprint).
Good suggestions, we will try to incorporate them.

> 
> As per the recent email thread, I believe there is consensus that the CDNI
> footprint & capabilities advertisement interface is all about helping the uCDN
> select a dCDN, and not about helping the uCDN to select a specific cache in
> the dCDN (at least for the initial CDNI WG work). While this is already
> implicitly reflected in the wording of requirements and description, I would
> recommend stating this explicitly to avoid confusion.
Ok, we can add a reference to this current consensus. Still, we are trying to explain the extreme cases of advertisement details, that's why I would like to have the extreme case example with direct redirection to caches in the dCDN still in the document.

> 
> 
> Regarding the section 1 statement "Footprint advertisement and capability
> advertisement need not use the same underlying protocol." :
> While this is true, it is interesting to consider this in light of the following
> statement in section 5 "The dCDN must be able to express particular
> capabilities for the delivery in a particular footprint area." Perhaps, it may be
> worth expanding the section 5 statement to point out that where capabilities
> are to be expressed on a per footprint area there _may_ be benefit in
> combining the footprint and capability advertisements.
Sure, we can add that.

Again, thanks for the detailed comments that will surely improve the draft.

 - Jan

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

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 22 Mar 2012 11:57:39 -0700

Tracking requirements from CDNI Interface drafts. Based on the
discussion for draft-spp-cdni-rr-foot-cap-semantics, I see numerous
requirements that were referenced. I noted that they were used as
clarifications in reviewing the draft. No comments required updates to
the requirements.

Just a note to CDNI Interface authors to provide me any requirement
issues encountered during the draft review. I may have missed some
issues following the topics. Thanks.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Le Faucheur (flefauch)
Sent: Tuesday, March 20, 2012 2:23 AM
To: [email-masked]
Subject: [CDNi] Few high level comments
redraft-spp-cdni-rr-foot-cap-semantics-00.txt

(As an individual),

For example:

	* when listing the cdni-requirements requirements, I recommend
the HIGH/MED/LOW prioritization be stated, as this is very significant
information on the current consensus of what is seen as essential for
the initial WG deliverables and what is not	

	* the "summary" of REQ-1 is misleading and needs to be changed.
It only quotes communicate "excessive load or failure condition"
suggesting the requirement is about exchanging load information, when
the requirement is actually about "coarse information about the
Downstream CDN ability and/or willingness to handle requests from the
Upstream CDN" and when mentioning load as _an example_ it qualifies it
as a "binary signal" -aka an aggregate CDN level busy-tone.

	* the generic requirements of cdni-requirements that strongly
affect the footprint & capabilities advertisement interface should be
included. In particular:
"   GEN-4   [HIGH] The CDNI solution shall not require intra-CDN
           information to be exposed to other CDNs for effective and
           efficient delivery of the content.  Examples of intra-CDN
           information include surrogate topology, surrogate status,
           cached content, etc.
"

In line with GEN-4, I believe the 2nd of the "candidates for definitions
of a footprint" listed in section 4 (ie "o  Footprint could be defined
as the set of the IP addresses of the caches deployed by a CDN.") can be
excluded (at least for initial CDNI WG work).

In line with GEN-4, I believe some of the candidate "capabilities"
listed in section 5 (ie  individual "Cache Capabilities are:   o  load,
or "excessive load",   o  available resources, storage resources,   o
failure conditions) can be excluded (at least for initial CDNI WG work).

In line with REQ-3, the 3rd bullet of section 4 should not read
"Potentially, a footprint may include ..." but something like "A
footprint needs to be able to include....". Also, I don't look at this
3rd bullet as an alternative candidate definition to the others: it is a
qualifier to the other definitions (ie whatever "footprint is", a given
footprint advertised by a CDN need to be able to reflect cascaded CDN
footprints in addition to the advertising CDN footprint).  

As per the recent email thread, I believe there is consensus that the
CDNI footprint & capabilities advertisement interface is all about
helping the uCDN select a dCDN, and not about helping the uCDN to select
a specific cache in the dCDN (at least for the initial CDNI WG work).
While this is already implicitly reflected in the wording of
requirements and description, I would recommend stating this explicitly
to avoid confusion.

Regarding the section 1 statement "Footprint advertisement and
capability advertisement need not use the same underlying protocol." :
While this is true, it is interesting to consider this in light of the
following statement in section 5 "The dCDN must be able to express
particular capabilities for the delivery in a particular footprint
area." Perhaps, it may be worth expanding the section 5 statement to
point out that where capabilities are to be expressed on a per footprint
area there _may_ be benefit in combining the footprint and capability
advertisements.

Cheers

Francois

> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics
-00.txt
> This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-
00.txt

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 22 Mar 2012 20:27:50 +0100

Hello Jan,

Looks like we've converged on most points. On the remaining ones:

On 22 Mar 2012, at 14:37, Jan Seedorf wrote:
> Not sure about this one. I read the requirement that the overall CDNI request routing needs to support cascaded CDNs, and that information exchanged needs to include cascaded dCDNs. The question at hand is if the "advertisement" part also needs to signal such cascading information EXPLICITLY, or if cascading CDNs merely need to be supported by the redirection part of the request routing interface,

I believe the "advertisement" part also needs to convey the cascaded information (but flowing in the opposite direction to request redirection of course).
Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as a dCDN, and where CDN2 may use CDN3 as a dCDN.
Then CDN3 would advertise its footprint to CDN2, and CDN2 would advertise to CDN1 a footprint that covers CDN2/s footprint and CDN3's footprint. This is necessary so that CDN1 can select CDN2 for a request that is within CDN3's footprint.
So the CDNI footprint advertisement problem comprises:
	* an interface between two CDNs to exchange footprint information
	* a logic to process incoming footprint information form a dCDN and decide if/how it is to be re-advertised/aggregated when advertising footprint to another CDN.
I recommend you discuss that aspect.

> i.e. the cascading information is IMPLICITLY included in the advertisement information. This is to me the open question, which we try to raise in the draft. But it is probably a good idea to clarify that a bit more in the draft and to cite the requirement above.
> 
> 
>> 

Fair enough. Some aggregated information may be reasonable. I suggest you change text which can currently be understood to mean per-cache information, into something explaining that aggregate info may be an interesting trade-off between not "disclosing too much" and being helpful for CDN selection by uCDN.

In fact, the binary/busy signal already mentioned in REQ-1 can be seen as a very aggregated "excessive load" signal.

> Ok, we can add a reference to this current consensus. Still, we are trying to explain the extreme cases of advertisement details,
> that's why I would like to have the extreme case example with direct redirection to caches in the dCDN still in the document.

Personally, I'm more interested in documenting the consensus on what we want to do, than extreme cases we don't really want to do, but I am fine if you want to bring them up as long as you identify them as such (ie extreme cases we can think of but know we don't want to do).

Cheers.

Francois

---

From: HeXiaoyan <[email-masked]>
Date: Fri, 23 Mar 2012 11:22:15 +0800

Hi,
Following the discussion on load, I share the view with Jan that load of
caches in a certain region(not any individual cache) make sense for an uCDN
to select a dCDN especially while assesses on other factors are quite
similar.

>Not sure. In my view, the dCDN could in principle express load not for
individual caches but for caches in a certain region without disclosing
details about its caches.

Best Regards
Xiaoyan(Susan) He

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jan
> Seedorf
> Sent: Thursday, March 22, 2012 9:37 PM
> To: Francois Le Faucheur; [email-masked]
> Subject: Re: [CDNi] Few high level comments re
> draft-spp-cdni-rr-foot-cap-semantics-00.txt
> 
> Hi Francois,
> 
the
> Ok, true. The intention for section 2 of our draft was simply to give some
> examples that have been mentioned in existing documents regarding the term
> "footprint" and "capability". Probably that was not precise in this case,
will
> update it.
> Not sure about this one. I read the requirement that the overall CDNI
request
> routing needs to support cascaded CDNs, and that information exchanged
> needs to include cascaded dCDNs. The question at hand is if the
> "advertisement" part also needs to signal such cascading information
> EXPLICITLY, or if cascading CDNs merely need to be supported by the
> redirection part of the request routing interface, i.e. the cascading
information
> is IMPLICITLY included in the advertisement information. This is to me the
open
> question, which we try to raise in the draft. But it is probably a good
idea to
> clarify that a bit more in the draft and to cite the requirement above.
> 
> 
> >
> Ok, good idea. Again, we only looked for example definitions in the reqs
> document for now, that's why it is not included so far. But you are right
that
> this requirement probably precludes certain capabilities.
> 
> >
of a
> > In line with GEN-4, I believe some of the candidate "capabilities"
listed in
> > section 5 (ie  individual "Cache Capabilities are:   o  load, or
"excessive
> load",
> Not sure. In my view, the dCDN could in principle express load not for
individual
> caches but for caches in a certain region without disclosing details about
its
> caches.
"Potentially, a
> > As per the recent email thread, I believe there is consensus that the
CDNI
> Ok, we can add a reference to this current consensus. Still, we are trying
to
> explain the extreme cases of advertisement details, that's why I would
like to
> have the extreme case example with direct redirection to caches in the
dCDN
> still in the document.
capability
> > While this is true, it is interesting to consider this in light of the
following
> > > A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-

---

From: Jan Seedorf <[email-masked]>
Date: Mon, 26 Mar 2012 17:32:16 +0000

Hi Francois,

Let me answer inline, but I think we are mostly in agreement:

> I believe the "advertisement" part also needs to convey the cascaded
> information (but flowing in the opposite direction to request redirection of
> course).
> Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as a
> dCDN, and where CDN2 may use CDN3 as a dCDN.
> Then CDN3 would advertise its footprint to CDN2, and CDN2 would advertise
> to CDN1 a footprint that covers CDN2/s footprint and CDN3's footprint. This is
> necessary so that CDN1 can select CDN2 for a request that is within CDN3's
> footprint.
I do not necessarily see why. In your example, if CDN2 implicitly includes CDN3's footprint in its footprint it advertises to uCDN, everything should work fine: uCDN is aware that dCDN can serve that footprint, but how exactly is none of uCDNs business, is it? :) Actually, I think therequirements doc says that the dCDN should not have to disclose internals like surrogate location etc. Why should it be forced to disclose its own business agreements with other dCDNs as long as advertises the correct overall information to the uCDN?

> * a logic to process incoming footprint information form a dCDN and decide
> if/how it is to be re-advertised/aggregated when advertising footprint to
> another CDN.
Discussing this aspect in more detail in the draft and documenting the design choices here is a good recommendation. We will try to make this aspect more clear in the next version, so that the reader can better understand what is the issue here (for me, as said below, the issue is IMPLICIT vs. EXPLICIT advertisement of transitive dCDN relationships).

> individual caches but for caches in a certain region without disclosing details
> about its caches.
> 
> 
> 
> Fair enough. Some aggregated information may be reasonable. I suggest you
> change text which can currently be understood to mean per-cache
> information, into something explaining that aggregate info may be an
> interesting trade-off between not "disclosing too much" and being helpful
> for CDN selection by uCDN.
> 
Ok, seems we agree here.

> 	Ok, we can add a reference to this current consensus. Still, we are
> trying to explain the extreme cases of advertisement details,
> 
> 	that's why I would like to have the extreme case example with direct
> redirection to caches in the dCDN still in the document.
> 
> 
> 
> Personally, I'm more interested in documenting the consensus on what we
> want to do, than extreme cases we don't really want to do, but I am fine if
> you want to bring them up as long as you identify them as such (ie extreme
> cases we can think of but know we don't want to do).
Understood and agree. We can clearly state that current WG consensus is not to have a direct redirection to dCDN surrogates. 

 - Jan

> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Thursday, March 22, 2012 8:28 PM
> To: Jan Seedorf
> Cc: Francois Le Faucheur; [email-masked]
> Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-
> semantics-00.txt
> 
> Hello Jan,
> 
> 		"   REQ-3   [MED] In the case of cascaded redirection, the 
> 
> CDNI Request-
> 
> 
> request routing needs to support cascaded CDNs, and that information
> exchanged needs to include cascaded dCDNs. The question at hand is if the
> redirection part of the request routing interface,
> 
> 
> I believe the "advertisement" part also needs to convey the cascaded
> information (but flowing in the opposite direction to request redirection of
> course).
> Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as a
> dCDN, and where CDN2 may use CDN3 as a dCDN.
> Then CDN3 would advertise its footprint to CDN2, and CDN2 would advertise
> to CDN1 a footprint that covers CDN2/s footprint and CDN3's footprint. This is
> necessary so that CDN1 can select CDN2 for a request that is within CDN3's
> footprint.
> * a logic to process incoming footprint information form a dCDN and decide
> if/how it is to be re-advertised/aggregated when advertising footprint to
> another CDN.
> 	i.e. the cascading information is IMPLICITLY included in the
> advertisement information. This is to me the open question, which we try to
> raise in the draft. But it is probably a good idea to clarify that a bit more in the
> draft and to cite the requirement above.
> 
> 
> 
> 
> 
> "excessive load",
> individual caches but for caches in a certain region without disclosing details
> about its caches.
> 
> 
> 
> Fair enough. Some aggregated information may be reasonable. I suggest you
> change text which can currently be understood to mean per-cache
> information, into something explaining that aggregate info may be an
> interesting trade-off between not "disclosing too much" and being helpful
> for CDN selection by uCDN.
> 
> 	Ok, we can add a reference to this current consensus. Still, we are
> trying to explain the extreme cases of advertisement details,
> 
> 	that's why I would like to have the extreme case example with direct
> redirection to caches in the dCDN still in the document.
> 
> 
> 
> Personally, I'm more interested in documenting the consensus on what we
> want to do, than extreme cases we don't really want to do, but I am fine if
> you want to bring them up as long as you identify them as such (ie extreme
> cases we can think of but know we don't want to do).
> 
> Cheers.
> 
> Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 27 Mar 2012 08:31:17 +0200

I think we have actually converged. See below:

> I do not necessarily see why. In your example, if CDN2 implicitly includes CDN3's footprint in its footprint it advertises to uCDN, everything should work fine:

We are actually saying the same thing ie that the footprint advertisement that CDN2 exchanges with CDN1 need to comprise the footprint coverage of CDN2 and of CDN3. I am not saying that the footprint coverage of CDN3 has to appear as CDN3, it can (and in fact I believe it should) appear as part of CDN2 footprint.

> uCDN is aware that dCDN can serve that footprint, but how exactly is none of uCDNs business, is it? :)

I agree.

> Actually, I think therequirements doc says that the dCDN should not have to disclose internals like surrogate location etc. Why should it be forced to disclose its own business agreements with other dCDNs as long as advertises the correct overall information to the uCDN?

I agree it shoudl not.

> Discussing this aspect in more detail in the draft and documenting the design choices here is a good recommendation. We will try to make this aspect more clear in the next version, so that the read…

Good.
Again, I believe this is important because the solution needs to not only facilitate exchange of footprint information between 2 neighbor CDNs, but also facilitate exchange of footprint information among an arbitrary mesh of CDNs, which brings a complete set of additional dimensions to the problem (re-advertising, aggregation, filtering, policy control, loop-prevention,...) and this is an important aspect of the problem definition and solution assessment.

Cheers

Francois

---

From: Jan Seedorf <[email-masked]>
Date: Tue, 27 Mar 2012 11:42:51 +0000

Hi Francois,

> I think we have actually converged.
I think so, too, good. Thanks for your comments, we will address them in the next version of the semantics draft to capture the discussion and to document key points / WG consensus / design decisions.

 - Jan

> Sent: Tuesday, March 27, 2012 8:31 AM
> To: Jan Seedorf
> > I do not necessarily see why. In your example, if CDN2 implicitly includes
> CDN3's footprint in its footprint it advertises to uCDN, everything should
> work fine:
> 
> We are actually saying the same thing ie that the footprint advertisement
> that CDN2 exchanges with CDN1 need to comprise the footprint coverage of
> CDN2 and of CDN3. I am not saying that the footprint coverage of CDN3 has
> to appear as CDN3, it can (and in fact I believe it should) appear as part of
> CDN2 footprint.
> 
> 
> > Actually, I think therequirements doc says that the dCDN should not have
> to disclose internals like surrogate location etc. Why should it be forced to
> disclose its own business agreements with other dCDNs as long as advertises
> the correct overall information to the uCDN?
> 
> I agree it shoudl not.
> 
> >
> > Discussing this aspect in more detail in the draft and documenting the
> design choices here is a good recommendation. We will try to make this
> aspect more clear in the next version, so that the reader can better
> understand what is the issue here (for me, as said below, the issue is
> IMPLICIT vs. EXPLICIT advertisement of transitive dCDN relationships).
> 
> Good.
> Again, I believe this is important because the solution needs to not only
> facilitate exchange of footprint information between 2 neighbor CDNs, but
> also facilitate exchange of footprint information among an arbitrary mesh of
> CDNs, which brings a complete set of additional dimensions to the problem
> (re-advertising, aggregation, filtering, policy control, loop-prevention,...) and
> this is an important aspect of the problem definition and solution
> assessment.
> 
> Cheers
> 
> Francois
> 
> >
> >
> details
> >> In fact, the binary/busy signal already mentioned in REQ-1 can be seen as
> a
> >> very aggregated "excessive load" signal.
> > Ok, seems we agree here.
> >
> >
> > Understood and agree. We can clearly state that current WG consensus is
> not to have a direct redirection to dCDN surrogates.
> >
> > - Jan
> >
> >
> >
> details
> >> In fact, the binary/busy signal already mentioned in REQ-1 can be seen as
> a
> >> very aggregated "excessive load" signal.
> >>
> >>
> >>