Subject: Re: [CDNi] Draft submitted on ALTO for CDNi request routing

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 14 Nov 2011 11:08:58 +0800

Hello Jan,

(as an individual)

I understand that your document :
	(i) discusses how ALTO could be used to effectively allow selection of dCDN Surrogate directly by the uCDN request router, AND
	(ii) mentions that ALTO could potentially be used to facilitate dCDN selection by uCDN.

Regarding (i), it is not clear to me that allow selection of dCDN Surrogate directly by the uCDN request router is a desirable goal considering the combination of the following:
	(a) the Working Group has agreed that the solution should not rely on dCDN exposing too much "internal" information: 
		"
	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.
		"
	(b) in general, selection of dCDN Surrogate is likely to depend on a number of criteria, including criteria beyond network proximity information (e.g. Surrogate cache/resource/status considerations), do I don't think that exposing dCDN proximity information to uCDN would be sufficient. In fact, I see that you have noticed that point since your draft does mention:
"An implicit assumption for the example in Figure 1 to work is that the CDN entry point for the downstream CDN only depends on the location of the end user."

Regarding (ii), I believe facilitating dCDN selection by uCDN is indeed a strong goal, but the draft does not yet discuss details of how ALTO could be used there.

Cheers

Francois

On 19 Oct 2011, at 23:52, Jan Seedorf wrote:

> CDNi folks, ALTO folks,
>  
> I have just submitted a new draft which discusses how ALTO could help in CDNi request routing:
>  
> Abstract:
> “… This document focusses on the Request Routing Interface of CDNi, and more specifically on how the solutions currently being defined in the Application Layer Traffic Optimization (ALTO) WG can improve CDNi request routing.  The overall intention behind this document is to foster discussions (in the CDNi as well as in the ALTO WG) regarding a) if, b) how, and c) under what conditions ALTO can be useful to optimize CDNi request routing.  As basis for this discussion, this document provides concrete examples of how ALTO can be integrated within CDNi request routing.  The examples in this   document are based on the use cases and examples currently being discussed in the CDNi WG.”
>  
> http://www.ietf.org/id/draft-seedorf-alto-for-cdni-00.txt
>  
> Comments (from CDNi WG and ALTO WG) are welcome,
>  
> -          Jan
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Jan Seedorf <[email-masked]>
Date: Mon, 14 Nov 2011 06:33:11 +0000

Dear Francois,

Thanks for your comments on the draft. Please find my answers below inline:

Jan: Actually, ALTO is designed in a way that leaves the degree of detail being disclosed through ALTO information at the ALTO server's (i.e. in this case at the dCDN's) discretion. To be concrete, ALTO is exactly a way to recommend a surrogate without disclosing the interior topology of the dCDN.

Jan: Maybe I should clarify (I think it says somehow in the draft as well) that the draft does not propose to have ALTO as the CDNi request routing itself, but rather that ALTO can be a part of it. Having said that, I think that the data contained in an ALTO cost map could be a combination of proximity/status/other criteria, again being combined totally at the dCDNs discretion and without disclosing these details to the uCDN. The ALTO cost value would just be a means to signal to the uCDN which surrogate is preferred from the dCDNs perspective.

Jan: indeed, this needs to be detailed in future versions of the draft. One example would be that ALTO maps from several candidate dCDNs could provide information to the uCDN of the footprint of these dCDNs or how close to the end user each dCDN can offer a surrogate. But such use cases need to be thought through a bit more.

I hope my answers clarified a bit, especially that ALTO information can be used in a way that it does not disclose (too many) details of the network topology.

-          Jan

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Monday, November 14, 2011 11:09 AM
To: Jan Seedorf
Cc: [email-masked]
Subject: Re: [CDNi] Draft submitted on ALTO for CDNi request routing

Hello Jan,

(as an individual)

Cheers

Francois

CDNi folks, ALTO folks,

Abstract:
"... This document focusses on the Request Routing Interface of CDNi, and more specifically on how the solutions currently being defined in the Application Layer Traffic Optimization (ALTO) WG can improve CDNi request routing.  The overall intention behind this document is to foster discussions (in the CDNi as well as in the ALTO WG) regarding a) if, b) how, and c) under what conditions ALTO can be useful to optimize CDNi request routing.  As basis for this discussion, this document provides concrete examples of how ALTO can be integrated within CDNi request routing.  The examples in this   document are based on the use cases and examples currently being discussed in the CDNi WG."

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 15 Nov 2011 01:03:46 +0800

On 14 Nov 2011, at 14:33, Jan Seedorf wrote:

> Jan: Actually, ALTO is designed in a way that leaves the degree of detail being disclosed through ALTO information at the ALTO server’s (i.e. in this case at the dCDN’s) discretion. To be concrete, ALTO is exactly a way to recommend a surrogate without disclosing the interior topology of the dCDN.
>  
> Jan: Maybe I should clarify (I think it says somehow in the draft as well) that the draft does not propose to have ALTO as the CDNi request routing itself,
> but rather that ALTO can be a part of it.
> Having said that, I think that the data contained in an ALTO cost map could be a combination of proximity/status/other criteria, again being combined totally at the dCDNs discretion and without disclosing these details to the uCDN. The ALTO cost value would just be a means to signal to the uCDN which surrogate is preferred from the dCDNs perspective.

Let's say for argument sake that the dCDN wants to select a surrogate taking into account 3 metrics:
	* Metric-1 that depends on enduser IP address and is fairly static
	* Metric-2 that depends on the content URI (because dCDN wants to increase cache hit ratio)
	* Metric-3 that is fairly dynamic (eg Surrogate load).

Assuming the dCDN is willing to make this information visible, I can see that the dCDN could provide a network map that would allow uCDN to take into account Metric-1.

Do you agree that ALTO itself would not naturally allow uCDN to factor Metric-2 and Metric-3?
And even whether it is ALTO or something else, would you agree that a solution allowing uCDN to factor in something like Metric-3 would probably involve exposing quite a bit of dCDN information and updating it very frequently?

> I hope my answers clarified a bit, especially that ALTO information can be used in a way that it does not disclose (too many) details of the network topology.

See above.
I would agree that, _if we want to support a solution where the uCDN performs dCDN surrogate selection_, then ALTO could be used to provide _some_ basic info that could be used by the uCDN in the dCDN Surrogate selection. But because surrogate selection in a CDN is a sophisticated multi-dimension dynamic vendor-specific decision, I am not convinced that it is possible to convey to the uCDN the _rest_ of the info that is really needed to make the complete surrogate selection in a way that is scalable, fresh-enough, covers all the fancy selection criteria out there and at the same time ensures the dCDN does not expose more than it wishes. In other words I don't think it is realistic to expect that uCDN can do dCDN surrogate selection on behalf of dCDN.
I'm interested in other opinions here.

Cheers

Francois

> Comments (from CDNi WG and ALTO WG) are welcome,

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: Jan Seedorf <[email-masked]>
Date: Tue, 15 Nov 2011 02:18:34 +0000

Dear Francois,

I actually agree with most of your points. Please find my reply inline below…

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Tuesday, November 15, 2011 1:04 AM
To: Jan Seedorf
Cc: Francois Le Faucheur; [email-masked]
Subject: Re: [CDNi] Draft submitted on ALTO for CDNi request routing

Dear Francois,

Jan: Yes, I agree. ALTO is – as described in RFC 5693 – for information that does not change frequently (RFC 5693: “The kind of information that is meaningful to convey to applications via an out-of-band ALTO service is any information that applications cannot easily obtain themselves and that changes on a much longer time scale than the instantaneous information used for congestion control on the transport layer”). Especially metric-2 is definitely something ALTO cannot provide, and metric 3 if it is “fairly” dynamic is out of scope for ALTO.

See above.

Jan: I think we have to separate “surrogate selection” and “CDN entry point” selection. Let’s assume a dCDN in the US does not want all requests from other countries’ uCDNs to arrive at a single gateway, but has several “entry points” for requests from a uCDN, say for simplicity in Seattle, Orlando, Los Angeles, and New York. Here I can see how providing an ALTO map to uCDNs can help these uCDNs to decide where to direct requests to (i.e. to which entry point out of several candidate ones) depending on the location (i.e. IP address) of the end user. For instance, a uCDN could use ALTO information to decide to which entry point of the dCDN it would direct a request coming from an end user in St. Louis.

Finally, I am of course also interested in other opinions from the WG.

-          Jan

Cheers

Francois

-          Jan

From: Francois Le Faucheur [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, November 14, 2011 11:09 AM
To: Jan Seedorf
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] Draft submitted on ALTO for CDNi request routing

Hello Jan,

(as an individual)

Cheers

Francois

CDNi folks, ALTO folks,

Abstract:

-          Jan

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]<mailto:[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<http://www.cisco.com>

 Think before you print.