Subject: [CDNi] Updating Ref Model picture in cdni-problem-statement?

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 8 Jul 2011 11:35:25 +0200

Ben, Nabil,

Are you OK with updating the Ref Model picture in the next rev of cdni-problem-statement as proposed below?

Cheers

Francois

Begin forwarded message:

> From: Francois Le Faucheur <[email-masked]>
> Date: 9 June 2011 15:40:26 CEST
> To: He Xiaoyan <[email-masked]>
> Cc: Francois Le Faucheur <[email-masked]>, [email-masked]
> Subject: Re: 答复: [CDNi] Comments on definition of recursive&iterative request routing
> 
> Hi again,
> 
> On 9 Jun 2011, at 05:08, He Xiaoyan wrote:
> 
>> Hi Francois,
>> Thanks for your reply.
>> Some further concerns.
>> “ie I'd picture that the cache in the downstream CDN (CDN2) will issue its inter-CDN acquisition request and that request will be handled directly by the upstream CDN Request Routing system (CDN1) - via HTTP or DNS, like a regular CDN scenario.”
>> Not very clear how that works because there is no interface between a delivery node and RR in another CDN of CDNI model as below.
> 
> We could show a "Request" interface between the "Surrogate" in the Downstream CDN and the Request Routing system in the Upstream CDN (ie same interface as the "Request" interface shown between the User-Agent and the uCDN/dCDN Request Routing system) like shown below.
> Does that help ?
> 
>      --------
>      /        \
>      |   CSP  |
>      \        /
>       --------
>           *
>           *
>           *                        /\
>           *                       /  \
>       ---------------------      |CDNI|       ---------------------
>      /    Upstream CDN     \     |    |      /   Downstream CDN    \
>      |     +-------------+ | Control protocol| +-------------+     |
>      |     |CDN Control  |<======|====|=======>| CDN Control |     |
>      |     +------*-*-*--+ |     |    |      | +-*-*-*-------+     |
>      |            * * *    |     |    |      |   * * *             |
>      |     +------*------+ | Logging protocol| +-----*-------+     |
>      | ****| Logging     |<======|====|=======>|  Logging    |**** |
>      | *   --------------+ |     |    |      | +-------------+   * |
>      | *            * *    | Request Routing |   * *             * |
>    ....*...+--------*----+ |    protocol     | +---*---------+...*.....
>    . | * **|Req-Routing  |<======|====|=======>| Req-Routing |** * |  .
>    . | * * +-------------+.|     |    |      | +-------------+ * * |  .
>    . | * *            *    .  CDNI Metatdata |   *             * * |  .
>    . | * * +----------*--+ |.    protocol     | +-*-----------+ * * |  .
>    . | * * |Distribution |<==.===|====|=======>| Distribution| * * |  .
>    . | * * |             | |  .   \  /       | |             | * * |  .
>    . | * * |             | |   .   \/        | |             | * * |  .
>    . | * ****+---------+ | |    ..Request........+---------+**** * |  .
>    . | ******|Surrogate|*************************|Surrogate|****** |  .
>    . |     | +---------+ | |   Acquisition   | | +-----*---+ |     |  .
>    . |     +-------------+ |                 | +-------*-----+     |  .
>    . \                     /                 \         *           /  .
>    .  ---------------------                   ---------*-----------   .
>    .                                                   *              .
>    .                                                   * Delivery     .
>    .                                                   *              .
>    .                                                +------+          .
>    ...............Request...........................| User |..Request..
>                                                     | Agent|
>                                                     +------+
> 
> 
> 
>> And I’m not sure if any additional security issues need to be considered when we talking about that a cache in the downstream CDN directly interact with the upstream CDN’s RR.
>>      --------
>>      /        \
>>      |   CSP  |
>>      \        /
>>       --------
>>           *
>>           *
>>           *                        /\
>>           *                       /  \
>>       ---------------------      |CDNI|       ---------------------
>>      /    Upstream CDN     \     |    |      /   Downstream CDN    \
>>      |     +-------------+ | Control protocol| +-------------+     |
>>      |     |CDN Control  |<======|====|=======>| CDN Control |     |
>>      |     +------*-*-*--+ |     |    |      | +-*-*-*-------+     |
>>      |            * * *    |     |    |      |   * * *             |
>>      |     +------*------+ | Logging protocol| +-----*-------+     |
>>      | ****| Logging     |<======|====|=======>|  Logging    |**** |
>>      | *   --------------+ |     |    |      | +-------------+   * |
>>      | *            * *    | Request Routing |   * *             * |
>>    ....*...+--------*----+ |    protocol     | +---*---------+...*.....
>>    . | * **|Req-Routing  |<======|====|=======>| Req-Routing |** * |  .
>>    . | * * +-------------+ |     |    |      | +-------------+ * * |  .
>>    . | * *            *    |  CDNI Metatdata |   *             * * |  .
>>    . | * * +----------*--+ |    protocol     | +-*-----------+ * * |  .
>>    . | * * |Distribution |<======|====|=======>| Distribution| * * |  .
>>    . | * * |             | |      \  /       | |             | * * |  .
>>    . | * * |             | |       \/        | |             | * * |  .
>>    . | * ****+---------+ | |                 | | +---------+**** * |  .
>>    . | ******|Surrogate|*************************|Surrogate|****** |  .
>>    . |     | +---------+ | |   Acquisition   | | +-----*---+ |     |  .
>>    . |     +-------------+ |                 | +-------*-----+     |  .
>>    . \                     /                 \         *           /  .
>>    .  ---------------------                   ---------*-----------   .
>>    .                                                   *              .
>>    .                                                   * Delivery     .
>>    .                                                   *              .
>>    .                                                +------+          .
>>    ...............Request...........................| User |..Request..
>>                                                     | Agent|
>>                                                     +------+
>> “I am not sure we'd want to invoke the CDNI Request Routing protocol at that stage (that is intended to operate across Request Routing systems). ie I'd picture that the cache in the downstream CDN (CDN2) will issue its inter-CDN acquisition request and that request will be handled directly by the upstream CDN Request Routing system (CDN1) - via HTTP or DNS, like a regular CDN scenario.”
>> I am not proposing CDNI Request Routing protocol must be invoked in dynamic content acquisition. But I think any possibilities should not be excluded in requirement stage.  In my understanding, election of mechanisms/solutions is job of next stage (framework?)?
> 
> Detailed mechanisms/solutions/protocols is to be done as part of the work on the actual "interfaces" but the Requirements I-D aims at identifying what functionality those need to support. 
> 
> Thank you.
> 
> Francois 
> 
> 
>> Thanks.
>>  
>> Best Regards
>> Xiaoyan(Susan) He
>> 发件人: Francois Le Faucheur [mailto:[email-masked]] 
>> 发送时间: 2011年6月9日 0:19
>> 收件人: He Xiaoyan
>> 抄送: Francois Le Faucheur; [email-masked]
>> 主题: Re: [CDNi] Comments on definition of recursive&iterative request routing
>>  
>> Hello He,
>>  
>> You are right that these definitions have been written with handling of enduser requests in mind (as opposed to handling of inter-CDN acquisition requests).
>>  
>> The logic is that the inter-CDN acquisition request (issued by a downstream CDN cache and pointing to the upstream CDN request routing system) can be considered simply as another request of its own (only, in that case, the "end user" happens to be a downstream CDN cache). Since the inter-CDN acquisition request is expected to come out of a cache (eg via a HTTP get), I am not sure we'd want to invoke the CDNI Request Routing protocol at that stage (that is intended to operate across Request Routing systems). ie I'd picture that the cache in the downstream CDN (CDN2) will issue its inter-CDN acquisition request and that request will be handled directly by the upstream CDN Request Routing system (CDN1) - via HTTP or DNS, like a regular CDN scenario. Of course, if the upstream CDN (CDN1) decided to redirect that particular (inter-CDN acquisition) request to a 3rd CDN (CDN3), then the iterative/recursive redirection would apply across these CDNs; but in this case, I think the current definitions actually work, because with respect to the inter-CDN acquisition request, CDN1 is the upstream CDN and CDN3 is the downstream CDN). (remember that the definitions of upstream CDN and downstream CDN are all relative to a given user request).
>>  
>> Thanks for looking into the Requirements document.
>>  
>> Francois
>>  
>>  
>> On 8 Jun 2011, at 04:23, He Xiaoyan wrote:
>> 
>> 
>> Hi all,
>> Some comments on definition of recursive and iterative request routing in I-D .draft-lefaucheur-cdni-requirements.
>> 1) “When an Upstream CDN elects to redirect a request towards a Downstream CDN,the Upstream CDN can query the Downstream CDN Request Routing system via the CDNI Request Routing protocol to find out how the Downstream CDN wants the request to be redirected …” This definition only covers requests initiated by users where upstream CDN will query the downstream CDN for routing decision. There is another case where recursive request routing is also utilized but not covered by this definition in CDNI, i.e. In case of cache miss and hence dynamic content acquisition invoked, for the content locate request issued by a delivery node of downstream CDN, the downstream CDN can query the upstream CDN on routing/redirection decision. In my view, these are two very similar scenarios with no essential difference on routing procedure.
>>  
>> 2) Similarly, for iterative request routing, the definition only covers the case that requests redirected from upstream CDN to downstream CDN, the direction that requests redirected from downstream CDN to upstream CDN for content locate requests in case of dynamic content acquisition is not covered.
>> Is the intent to exclude routings for content locate requests or something else?
>> Thanks.
>>  
>> Best Regards
>> Xiaoyan(Susan) He
>>  
>> _______________________________________________
>> CDNi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cdni
>>  
>>  
>>  
>> 
>> Francois Le Faucheur
>> Distinguished Engineer
>> Corporate Development
>> [email-masked]
>> Phone: +33 49 723 2619
>> Mobile: +33 6 19 98 50 90
>> 
>> 
>> Cisco Systems France
>> Greenside
>> 400 Ave de Roumanille
>> 06410 Sophia Antipolis
>> France
>> Cisco.com
>> 
>>  
>> 
>>  
>>  Think before you print.
>> 
>> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
>> 
>> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 �, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
>> 
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>> 
>>  
> 
> 
> 
> Francois Le Faucheur
> Distinguished Engineer
> Corporate Development
> [email-masked]
> Phone: +33 49 723 2619
> Mobile: +33 6 19 98 50 90
> 
> 
> 
> Cisco Systems France
> Greenside
> 400 Ave de Roumanille
> 06410 Sophia Antipolis
> France
> Cisco.com
> 
> 
>  
> 
> 
>  Think before you print.
> 
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
> 
> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 �, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
> 
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 �, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 27 Jul 2011 19:43:41 +0100

Francois, Colleagues,

My personal opinion is that we should not update the reference model like that, because it starts to introduce implementation specifics into the reference model.

Acquisition between CDNs is largely similar to acquisition from any other Origin. There are a multitude of ways for how a given Origin/UpstreamCDN may resolve into an actual server that will deliver the content to the surrogate. The downstream CDN will be provided (via the Content Distribution Metadata) details (e.g. a hostname) from which to acquire content for a given CDN service. Using the upstream CDN request router to resolve that hostname is just one possible way to implement the hostname resolution and I believe calling it out explicitly doesn't add anything except risking making the diagram more confusing (it's already pretty "messy" and complex) and implying a particular implementation of something that is already declared out of scope for CDNI.

Ben

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 27 Jul 2011 13:53:12 -0700

My interpretation of the CDNI Model figure - "Acquisition" Interface (out of scope) is used to distribute content between uCDN and dCDN without the need to involve the CDNI Request Routing function in the uCDN.  The content acquisition may involve intra-CDN request routing in the uCDN.  

My view is that the CDNI architecture depicts the CDNI functions and interfaces between relevant components.  We should clarify if there is an interface between the dCDN Surrogate and uCDN CDNI Request Routing function.  IMHO, this interface exists.  Though uCDN may decide not to use such an interface for content distribution.  But that's deployment option and the architecture should be complete.

Note, I've explicitly noted "CDNI Request Routing function" to differentiate from general request routing which can be used for intra-CDN redirection.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Wednesday, July 27, 2011 11:44 AM
To: Francois Le Faucheur (flefauch)
Cc: [email-masked]
Subject: Re: [CDNi] Updating Ref Model picture in cdni-problem-statement?

Francois, Colleagues,

Ben

On 8 Jul 2011, at 10:35, Francois Le Faucheur wrote:

>>>                                                     +------+ “I am 
>>> not sure we'd want to invoke the CDNI Request Routing protocol at that stage (that is intended to operate across Request Routing systems). ie I'd picture that the cache in the downstream CDN (CDN2) will issue its inter-CDN acquisition request and that request will be handled directly by the upstream CDN Request Routing system (CDN1) - via HTTP or DNS, like a regular CDN scenario.”
>>> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
>>> 
>> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
>> 
> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
>

---

From: He Xiaoyan <[email-masked]>
Date: Thu, 28 Jul 2011 11:36:28 +0800

Hi all,
I share the view that the CDNI architecture should be complete to cover the
option even if it is not the only way to solve the problem. The current
figure does not include the interface between dCDN surrogate and CDNI
Request Routing of an uCDN which may be involved during content acquisition.
To support interconnection of CDNs from different administrative entities,
this interface should be specified and hence should be in the scope of CDNI.

Best Regards
Xiaoyan(Susan) He

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Kent Leung
(kleung)
发送时间: 2011年7月28日 4:53
收件人: Ben Niven-Jenkins; Francois Le Faucheur (flefauch)
抄送: [email-masked]
主题: Re: [CDNi] Updating Ref Model picture in cdni-problem-statement?

My interpretation of the CDNI Model figure - "Acquisition" Interface (out of
scope) is used to distribute content between uCDN and dCDN without the need
to involve the CDNI Request Routing function in the uCDN.  The content
acquisition may involve intra-CDN request routing in the uCDN.  

My view is that the CDNI architecture depicts the CDNI functions and
interfaces between relevant components.  We should clarify if there is an
interface between the dCDN Surrogate and uCDN CDNI Request Routing function.
IMHO, this interface exists.  Though uCDN may decide not to use such an
interface for content distribution.  But that's deployment option and the
architecture should be complete.

Note, I've explicitly noted "CDNI Request Routing function" to differentiate
from general request routing which can be used for intra-CDN redirection.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben
Niven-Jenkins
Sent: Wednesday, July 27, 2011 11:44 AM
To: Francois Le Faucheur (flefauch)
Cc: [email-masked]
Subject: Re: [CDNi] Updating Ref Model picture in cdni-problem-statement?

Francois, Colleagues,

My personal opinion is that we should not update the reference model like
that, because it starts to introduce implementation specifics into the
reference model.

Acquisition between CDNs is largely similar to acquisition from any other
Origin. There are a multitude of ways for how a given Origin/UpstreamCDN may
resolve into an actual server that will deliver the content to the
surrogate. The downstream CDN will be provided (via the Content Distribution
Metadata) details (e.g. a hostname) from which to acquire content for a
given CDN service. Using the upstream CDN request router to resolve that
hostname is just one possible way to implement the hostname resolution and I
believe calling it out explicitly doesn't add anything except risking making
the diagram more confusing (it's already pretty "messy" and complex) and
implying a particular implementation of something that is already declared
out of scope for CDNI.

Ben

On 8 Jul 2011, at 10:35, Francois Le Faucheur wrote:

> Ben, Nabil,
> 
> Are you OK with updating the Ref Model picture in the next rev of
cdni-problem-statement as proposed below?
>>> “ie I'd picture that the cache in the downstream CDN (CDN2) will issue
its inter-CDN acquisition request and that request will be handled directly
by the upstream CDN Request Routing system (CDN1) - via HTTP or DNS, like a
regular CDN scenario.”
>>> Not very clear how that works because there is no interface between a
delivery node and RR in another CDN of CDNI model as below.
>> 
>> We could show a "Request" interface between the "Surrogate" in the
Downstream CDN and the Request Routing system in the Upstream CDN (ie same
interface as the "Request" interface shown between the User-Agent and the
uCDN/dCDN Request Routing system) like shown below.
>>> And I’m not sure if any additional security issues need to be
considered when we talking about that a cache in the downstream CDN directly
interact with the upstream CDN’s RR.
>>> not sure we'd want to invoke the CDNI Request Routing protocol at that
stage (that is intended to operate across Request Routing systems). ie I'd
picture that the cache in the downstream CDN (CDN2) will issue its inter-CDN
acquisition request and that request will be handled directly by the
upstream CDN Request Routing system (CDN1) - via HTTP or DNS, like a regular
CDN scenario.”
>>> I am not proposing CDNI Request Routing protocol must be invoked in
dynamic content acquisition. But I think any possibilities should not be
excluded in requirement stage.  In my understanding, election of
mechanisms/solutions is job of next stage (framework?)?
>> 
>> Detailed mechanisms/solutions/protocols is to be done as part of the work
on the actual "interfaces" but the Requirements I-D aims at identifying what
functionality those need to support. 
>>> You are right that these definitions have been written with handling of
enduser requests in mind (as opposed to handling of inter-CDN acquisition
requests).
>>>  
>>> The logic is that the inter-CDN acquisition request (issued by a
downstream CDN cache and pointing to the upstream CDN request routing
system) can be considered simply as another request of its own (only, in
that case, the "end user" happens to be a downstream CDN cache). Since the
inter-CDN acquisition request is expected to come out of a cache (eg via a
HTTP get), I am not sure we'd want to invoke the CDNI Request Routing
protocol at that stage (that is intended to operate across Request Routing
systems). ie I'd picture that the cache in the downstream CDN (CDN2) will
issue its inter-CDN acquisition request and that request will be handled
directly by the upstream CDN Request Routing system (CDN1) - via HTTP or
DNS, like a regular CDN scenario. Of course, if the upstream CDN (CDN1)
decided to redirect that particular (inter-CDN acquisition) request to a 3rd
CDN (CDN3), then the iterative/recursive redirection would apply across
these CDNs; but in this case, I think the current definitions actually work,
because with respect to the inter-CDN acquisition request, CDN1 is the
upstream CDN and CDN3 is the downstream CDN). (remember that the definitions
of upstream CDN and downstream CDN are all relative to a given user
request).
>>> Some comments on definition of recursive and iterative request routing
in I-D .draft-lefaucheur-cdni-requirements.
>>> 1) “When an Upstream CDN elects to redirect a request towards a
Downstream CDN,the Upstream CDN can query the Downstream CDN Request Routing
system via the CDNI Request Routing protocol to find out how the Downstream
CDN wants the request to be redirected …” This definition only covers
requests initiated by users where upstream CDN will query the downstream CDN
for routing decision. There is another case where recursive request routing
is also utilized but not covered by this definition in CDNI, i.e. In case of
cache miss and hence dynamic content acquisition invoked, for the content
locate request issued by a delivery node of downstream CDN, the downstream
CDN can query the upstream CDN on routing/redirection decision. In my view,
these are two very similar scenarios with no essential difference on routing
procedure.
>>>  
>>> 2) Similarly, for iterative request routing, the definition only covers
the case that requests redirected from upstream CDN to downstream CDN, the
direction that requests redirected from downstream CDN to upstream CDN for
content locate requests in case of dynamic content acquisition is not
covered.
>>> This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.
>>> 
>>> Cisco Systems France, Société à responsabiité limitée, Rue Camille
Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux,
Au capital de 91.470 �, 349 166 561 RCS Nanterre, Directeur de la
publication: Jean-Luc Michel Givone.
>> This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.
>> 
>> Cisco Systems France, Société à responsabiité limitée, Rue Camille
Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux,
Au capital de 91.470 �, 349 166 561 RCS Nanterre, Directeur de la
publication: Jean-Luc Michel Givone.
> This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.
> 
> Cisco Systems France, Société à responsabiité limitée, Rue Camille
Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux,
Au capital de 91.470 �, 349 166 561 RCS Nanterre, Directeur de la
publication: Jean-Luc Michel Givone.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 28 Jul 2011 05:02:39 +0100

Don't confuse the CDNI Request Routing interface (which is for communicating information between the request routing systems in different CDNs) with the "regular" request routing performed by CDNs today (and which would still exist in a world where CDNI is deployed).

The CDNI Metadata may include an Origin hostname that ultimately resolves to the Request Routing function in the upstream CDN but that does not involve the CDNI Request Routing interface.

I see no need for a downstream CDN Surrogate to make use of the CDNI Request Routing interface for acquisition and the proposed change to the reference model is not across the CDNI Request Routing interface but between the downstream CDN Surrogate and the "regular" request routing function of the upstream CDN (and would have been marked out of scope for CDNI).

Ben

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 27 Jul 2011 21:24:37 -0700

My understanding is that the proposed change is adding the interface between the dCDN Surrogate and the uCDN CDNI Request Routing function (i.e., not normal request routing).  Is there a reason this should be disallowed?  I agree that there are implications for using this method for content distribution between CDNs.  But I think it's OK to just acknowledge such interface exists and mark as out of scope for now. 

Kent

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 9:03 PM
To: He Xiaoyan
Cc: Kent Leung (kleung); Francois Le Faucheur (flefauch); [email-masked]
Subject: Re: 答复: [CDNi] Updating Ref Model picture in cdni-problem-statement?

Ben

On 28 Jul 2011, at 04:36, He Xiaoyan wrote:

> Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la
> Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la
> Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 28 Jul 2011 06:00:54 +0100

The original comment that initiated the proposal to show the interface between a downstream CDN surrogate and upstream CDN's request routing function was:

"The logic is that the inter-CDN acquisition request (issued by a
request)."

where the key phrase is "(CDN2) will issue its inter-CDN acquisition request and that request will be handled directly by the upstream CDN Request Routing system (CDN1) - via HTTP or DNS, like a regular CDN scenario."

which is clearly referring to the "regular" request routing in the upstream CDN.

I don't believe there is a need to document that as it just confuses what is already a complex diagram while adding no value to the reference model (and IMO using regular request routing like that is trivially obvious). 

I don't see a need for downstream CDN surrogates to make use of the CDNI Request Routing interface for acquisition (and therefore I don;t see any need to acknowledge/document the existence of such an interface). If you or someone else do see a need, can you describe a use case that would illustrate why it is needed?

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 27 Jul 2011 22:21:14 -0700

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 10:01 PM
To: Kent Leung (kleung)
Cc: He Xiaoyan; Francois Le Faucheur (flefauch); [email-masked]
Subject: Re: 答复: [CDNi] Updating Ref Model picture in cdni-problem-statement?

KL> OK.  I see why you've interpreted that way.  I saw "(CDN2) will issue its inter-CDN acquisition request and that request will be handled directly by the upstream CDN Request Routing system (CDN1)" and then later, " if the upstream CDN (CDN1) decided to redirect that particular (inter-CDN acquisition) request to a 3rd CDN (CDN3), then the iterative/recursive redirection would apply across these CDNs".  So I interpreted that CDN2 sent request to CDN1 which can decide to redirect to CDN3 (as the 3rd CDN).  This would require CDN1's CDNI Request Routing function to be involved.  I've assumed this is the cascaded scenario.

We'll let Susan clarify to avoid mis-interpretations. :)

Kent

<snip>

---

From: He Xiaoyan <[email-masked]>
Date: Thu, 28 Jul 2011 15:35:49 +0800

Hi Ben and all,
In my proposal a hostname should also be provided to the downstream CDN to
acquire content, I think at this point, we do not have any conflict.
What I'm trying to say is the hostname provided to the downstream CDN should
always point to the Request Routing function in the upstream CDN. It's up to
the Request Routing function of the upstream CDN to decide the next hop for
the content acquisition of the downstream CDN, e.g. A storage server of the
Upstream CDN or the origin server of the CP, or the Request Routing function
of the 3rd cascaded CDN.

Furthermore, as the "regular" request routing mechanisms used intra CDNs may
be different, e.g. some CDNs utilizing DNS, whilst others utilizing HTTP
GET.  Though it is very similar to a "regular" request routing performed by
CDNs today, but as components from different CDNs involved, it should be
specified or at least the mechanisms (DNS, HTTP) used across these CDNs
should be specified to interconnect.

Best Regards
Xiaoyan(Susan) He

-----邮件原件-----
发件人: Ben Niven-Jenkins [mailto:[email-masked]] 
发送时间: 2011年7月28日 12:03
收件人: He Xiaoyan
抄送: 'Kent Leung (kleung)'; 'Francois Le Faucheur (flefauch)';
[email-masked]
主题: Re: 答复: [CDNi] Updating Ref Model picture in cdni-problem-statement?

Don't confuse the CDNI Request Routing interface (which is for communicating
information between the request routing systems in different CDNs) with the
"regular" request routing performed by CDNs today (and which would still
exist in a world where CDNI is deployed).

The CDNI Metadata may include an Origin hostname that ultimately resolves to
the Request Routing function in the upstream CDN but that does not involve
the CDNI Request Routing interface.

I see no need for a downstream CDN Surrogate to make use of the CDNI Request
Routing interface for acquisition and the proposed change to the reference
model is not across the CDNI Request Routing interface but between the
downstream CDN Surrogate and the "regular" request routing function of the
upstream CDN (and would have been marked out of scope for CDNI).

Ben

---

From: He Xiaoyan <[email-masked]>
Date: Thu, 28 Jul 2011 15:52:47 +0800

Hi Kent et all,
Respond via another email of this thread.
Further comments are welcomed.

Best Regards
Xiaoyan(Susan) He

-----邮件原件-----
发件人: Kent Leung (kleung) [mailto:[email-masked]] 
发送时间: 2011年7月28日 13:21
收件人: Ben Niven-Jenkins
抄送: He Xiaoyan; Francois Le Faucheur (flefauch); [email-masked]
主题: RE: 答复: [CDNi] Updating Ref Model picture in cdni-problem-statement?

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 10:01 PM
To: Kent Leung (kleung)
Cc: He Xiaoyan; Francois Le Faucheur (flefauch); [email-masked]
Subject: Re: 答复: [CDNi] Updating Ref Model picture in
cdni-problem-statement?

The original comment that initiated the proposal to show the interface
between a downstream CDN surrogate and upstream CDN's request routing
function was:

where the key phrase is "(CDN2) will issue its inter-CDN acquisition request
and that request will be handled directly by the upstream CDN Request
Routing system (CDN1) - via HTTP or DNS, like a regular CDN scenario."

which is clearly referring to the "regular" request routing in the upstream
CDN.

KL> OK.  I see why you've interpreted that way.  I saw "(CDN2) will issue
its inter-CDN acquisition request and that request will be handled directly
by the upstream CDN Request Routing system (CDN1)" and then later, " if the
upstream CDN (CDN1) decided to redirect that particular (inter-CDN
acquisition) request to a 3rd CDN (CDN3), then the iterative/recursive
redirection would apply across these CDNs".  So I interpreted that CDN2 sent
request to CDN1 which can decide to redirect to CDN3 (as the 3rd CDN).  This
would require CDN1's CDNI Request Routing function to be involved.  I've
assumed this is the cascaded scenario.

Kent

<snip>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 28 Jul 2011 16:25:43 +0100

Susan,

> Upstream CDN or the origin server of the CP, or the Request Routing function

Why force such behaviour, rather than leaving it to the upstream CDN to decide how it wants to implement the resolution of the "origin"/"content source" hostnames it provides to downstream CDNs? Pointing the hostname to the upstream CDN request routing function is a reasonable thing to do but I see no reason to force such behaviour as it is just unnecessarily limiting implementation flexibility.

Ben

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 28 Jul 2011 10:52:13 -0700

Hi Ben and Susan.  I'll chime in with an example.  Let's say uCDN has a certain capacity for distribution/delivery by its Surrogates.  It provides the CDNI Metadata to dCDN to send request to uCDN's CDNI RR function to acquire content.  Under normal conditions, uCDN's CDNI RR function decides to use its Surrogates to deliver content to dCDN.  However, when uCDN's Surrogates are overloaded, its CDNI RR function will redirect the request from dCDN to another CDN, serving as over-flow capacity (i.e. overflow handling and dimensioning use case).  Basically, the reasons to use CDNI apply not just to User Agent's request, but also for dCDN's content acquisition request (CDNI distribution).  

I see this as an option for the uCDN to ensure highly available distribution service.  The uCDN does not have to use this interface for content distribution.  So it doesn't seem "forced" to me.  Just the opposite, it adds flexibility and takes advantages of the benefits of CDNI.  Though I think we need to think through the implications.  I do see value for such an interface.

Kent

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 8:26 AM
To: He Xiaoyan
Cc: Kent Leung (kleung); Francois Le Faucheur (flefauch); [email-masked]
Subject: Re: 答复: 答复: [CDNi] Updating Ref Model picture in cdni-problem-statement?

Susan,

Ben

---

From: He Xiaoyan <[email-masked]>
Date: Fri, 29 Jul 2011 17:03:09 +0800

Hi Kent and Ben,
Thanks for you example and reply. I accept it's an option for content
distribution. The uCDN does not have to use it for content distribution. 

Best Regards
Xiaoyan(Susan) He

-----邮件原件-----
发件人: Kent Leung (kleung) [mailto:[email-masked]] 
发送时间: 2011年7月29日 1:52
收件人: Ben Niven-Jenkins; He Xiaoyan
抄送: Francois Le Faucheur (flefauch); [email-masked]
主题: RE: 答复: 答复: [CDNi] Updating Ref Model picture in
cdni-problem-statement?

Hi Ben and Susan.  I'll chime in with an example.  Let's say uCDN has a
certain capacity for distribution/delivery by its Surrogates.  It provides
the CDNI Metadata to dCDN to send request to uCDN's CDNI RR function to
acquire content.  Under normal conditions, uCDN's CDNI RR function decides
to use its Surrogates to deliver content to dCDN.  However, when uCDN's
Surrogates are overloaded, its CDNI RR function will redirect the request
from dCDN to another CDN, serving as over-flow capacity (i.e. overflow
handling and dimensioning use case).  Basically, the reasons to use CDNI
apply not just to User Agent's request, but also for dCDN's content
acquisition request (CDNI distribution).  

I see this as an option for the uCDN to ensure highly available distribution
service.  The uCDN does not have to use this interface for content
distribution.  So it doesn't seem "forced" to me.  Just the opposite, it
adds flexibility and takes advantages of the benefits of CDNI.  Though I
think we need to think through the implications.  I do see value for such an
interface.

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 8:26 AM
To: He Xiaoyan
Cc: Kent Leung (kleung); Francois Le Faucheur (flefauch); [email-masked]
Subject: Re: 答复: 答复: [CDNi] Updating Ref Model picture in
cdni-problem-statement?

Susan,

> Upstream CDN or the origin server of the CP, or the Request Routing
function

Why force such behaviour, rather than leaving it to the upstream CDN to
decide how it wants to implement the resolution of the "origin"/"content
source" hostnames it provides to downstream CDNs? Pointing the hostname to
the upstream CDN request routing function is a reasonable thing to do but I
see no reason to force such behaviour as it is just unnecessarily limiting
implementation flexibility.

Ben

>> hostname is just one possible way to implement the hostname resolution
and
> I
>>>> Subject: Re: 答复: [CDNi] Comments on definition of recursive&iterative

>>>> request routing
>>>>> 主题: Re: [CDNi] Comments on definition of recursive&iterative request

>>>>> routing