Subject: [CDNi] draft-choi-cdni-req-routing-redir-loop-prevention-00.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 18 Jul 2012 16:52:21 +0000

Hello Taesang,

Just had a quick look at your document. Here are a few early questions and comments.

1) I think what you call "CDN-Provider-ID" is actually (i) a dynamic record of the CDNs in the CDN path + a "TTL" expressed in number of redirection hops.
I'd suggest you give it another name than "CDN-Provider-ID" as this tend to suggest an identifier for a single CDN. Perhaps you could call this something like a "CDN Path Record" or "CDN path"…
When you give an example of "CDN Path Record", I suggest you provide an example that contains more than 1 CDN, just to make it clearer.

2) In the case of HTTP I am unclear as to whether yu are proposing to have the "CDN Path Record" conveeyed :
	(i) in a TBD HTTP header, 
	(ii) inside the URI hostname, or
	(iii) inside the URI query string

The text : "For HTTP- based redirection, we define a HTTP request routing redirection header "CDN-Provider-ID" suggests (i).
The text "For each step of redirection, it is attached to the beginning of the provider domain URL." suggests (ii).
The text : "peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID" suggests (iii).

3) algorithm in case of loop detection.
You say:
"If a loop is detected and myself can serve the request, the request
   is processed in my CDN.  For some reason, if myself cannot process
   the request, it first checks availability of its parent and then
   uCDN.  If none of them succeed, then request is denied.
"
If a loop is detected, the CDN detecting the loop can decide to serve the request as you suggest, or arguably could decide to pick an alternative dCDN. Is there a reason you seem to exclude that option?

Cheers

Francois

> 
> 
> -----Original Message-----
> From: 최태상 
> Sent: Tuesday, July 17, 2012 12:50 AM
> To: [email-masked]'
> Subject: FW: New Version Notification for draft-choi-cdni-req-routing-redir-loop-prevention-00.txt
> 
> Dear all,  
> 
> We have uploaded a new I-D related to 'CDNI Request Routing Redirection with Loop Prevention' as below.  We request your review and comments
> 
> Thanks, 
> Taesang Choi
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 05, 2012 10:58 PM
> To: 최태상
> Cc: [email-masked]
> Subject: New Version Notification for draft-choi-cdni-req-routing-redir-loop-prevention-00.txt
> 
> 
> 
> A new version of I-D, draft-choi-cdni-req-routing-redir-loop-prevention-00.txt
> has been successfully submitted by Taesang Choi and posted to the IETF repository.
> 
> Filename:	 draft-choi-cdni-req-routing-redir-loop-prevention
> Revision:	 00
> Title:		 CDNi Request Routing Redirection with Loop Prevention
> Creation date:	 2012-07-04
> WG ID:		 Individual Submission
> Number of pages: 20
> URL:             http://www.ietf.org/internet-drafts/draft-choi-cdni-req-routing-redir-loop-prevention-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-choi-cdni-req-routing-redir-loop-prevention
> Htmlized:        http://tools.ietf.org/html/draft-choi-cdni-req-routing-redir-loop-prevention-00
> 
> 
> Abstract:
>   This document describes request routing redirection procedures, loop
>   prevention mechanisms, and other operational considerations which are
>   associated with redirection.
> 
> 
> 
> 
> 
> 
> The IETF Secretariat

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 19 Jul 2012 12:36:54 +0000

Hi Taesang,

Please see below:

On 19 Jul 2012, at 13:44, 최태상 wrote:

> Dear Francois,
> 
> Thanks for your comments.  My in-line response is as follows:
> 
> 
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
> Sent: Thursday, July 19, 2012 1:52 AM
> To: 최태상
> Cc: [email-masked]
> Subject: draft-choi-cdni-req-routing-redir-loop-prevention-00.txt
> 
> Hello Taesang,
> 
> I'd suggest you give it another name than "CDN-Provider-ID" as this tend to suggest an identifier for a single CDN. Perhaps you could call this something like a "CDN Path Record" or "CDN path"… When you give an example of "CDN Path Record", I suggest you provide an example that contains more than 1 CDN, just to make it clearer.
> 
> ==> My intention was to make CDN-Provider-ID unique to a particular CDN provider.  As described, it consists of CDN provider Name and TTL.  

Well the text actually says:
"
It consists of "CDN provider list" and "MaxNumRedHops".  The CDN provider list is a set of uniquely identifiable CDN provider names.
"
So the text does not quite convey what you intended.

But anyways, I think there is agreement that what is needed is to somehow record the "CDN-Path" built as a series of CDN identifiers.

> Uniqueness is guaranteed because CDN Provider Name is based on AS number.  Main reasons for such a proposal are two-fold:  one is for uniqueness and the other is for saving space in the URL.  If we use extension of domain name for such purposes as described in the framework draft, space available in URI hostname may not be enough if the depth of cascaded redirection becomes large.  Also global uniqueness may not be guaranteed since duplicated extended domain names can be used accidentally.  Thus, the name CDN-Provider-ID serves our intended purpose.
>  However, it is ok with us to use the proposed name, i.e., CDN Path Record change any intended semantics.  How it is carried in URL is shown below with an example.
> 
> ==>  Thanks for pin-pointing inconsistency in the drafts.  There were some unintentionally mistakes during draft preparation.  Our intention to carry CDN-Provider-ID in URL is inside URI query string.  One example for the case that redirection is cascaded three times, (uCDN -> dCDN1 -> dCDN2) dCDN2 carries URL as given below to another dCDN if further redirection is needed.
> 
> http://cdn.csp.com?uCDN-Provider-ID=100:0:10&dCDN1-Provider-ID=200:1:9&dCDN2-Provider-ID=300:0:8

This example assumes that a TTL value is signaled for each level (10, 9 and 8). Do you see a need to convey the TTL of each CDN level as opposed to only the latest TTL value? 
eg: http://cdn.csp.com?CDNI-CID0=100:0&CDNI-CID1=200:1&CDNI-CID2=300:0&CDNI-TTL=8

> 
> In the section 2.1 of my draft gives one example as "http://100:0:10.cdn.csp.com".  It is used to describe abstract form to cover both HTTP-based and DNS-based cases.  For clarity, the text needs to be fixed to describe both cases separately.
> 
> 	
> ==> The proposed algorithm shows one possible but most general option for post-processing of loop detection.  That is, it assumes resource availability of its own parent until it reaches uCDN provider.  However, there are other post-processing alternatives which weren't described in the draft.  They are:
> 
> 1. When a loop detected, deny the service.  This is most strict case.
> 2. The second method is the one described in the draft.  It is general and reasonable post-processing case.
> 3. The third method is to allow parent dCDN to redirect another dCDN as you commented above.
> 4. The fourth method is to check the resource availability up until uCDN.  If uCDN still cannot serve, then it can start redirection process again except the path it just tried.  This method is the most general but rather in-efficient case.  It may have to consume all the TTL value. Although we just recommended one method, it can describe all possible methods in the draft as well.

So I think we agree there are other algorithm.
Personally I don't thionk we need to specify the algorithm. We only need to specify:
	(i) a mechanism to allow loop detection
	(ii) who is responsible for detecting and resolving the situation (and make sure that the loop detection algorithm can apply recursively so that if a subsequent loop happens it is again detected and solved).
Would you agree?

Cheers

Francois

>> Subject: FW: New Version Notification for 
>> draft-choi-cdni-req-routing-redir-loop-prevention-00.txt
>> 
>> Dear all,
>> 
>> We have uploaded a new I-D related to 'CDNI Request Routing 
>> Redirection with Loop Prevention' as below.  We request your review 
>> and comments
>> 
>> Thanks,
>> Taesang Choi
>> 
>> Subject: New Version Notification for 
>> draft-choi-cdni-req-routing-redir-loop-prevention-00.txt
>> 
>> 
>> 
>> A new version of I-D, 
>> draft-choi-cdni-req-routing-redir-loop-prevention-00.txt