Subject: [CDNi] Comments on draft-he-cdni-routing-request-redirection-03.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 5 Nov 2012 23:33:55 +0000

Hello,

(As an Individual).

In general, I feel this new version is going in the right direction.

Some high level comments:

	* I think the spec should be less prescriptive as to how a dCDN builds its redirection response. For example in section 6.1.1, the text says:
"If the dCDN decides to use DNS Redirection, where the Downstream CDN
   is redirecting directly to a surrogate in the Downstream CDN: the
   Downstream CDN selects one or more surrogates and returns a CDNI RRRI
   response containing the IP addresses of the selected surrogate(s), ...
 If the dCDN decides to use DNS Redirection, where the Downstream CDN
   is redirecting to a Request Router in the dCDN: : the Downstream CDN
   returns a CDNI RRRI response containing a CNAME of the Downstream
   CDN's Request Router(s), …
"
In this example, I think the dCDN should be free to return an IP address or a CNAME of the "redirection target" as it sees fit. The redirection target may be a Surrogate, a Request Router, a set of Surrogates, a 3rd party CDN Req Router, a 3rd party CDN Surrogate in case of cascaded CDNs,... whatever the dCDN sees fit.
You could possibly mention one of the behavior above as an example of what might happen, but it should just be an example and I recommend the spec be open as to the logic to populate the Redirection response.

* the document keeps talking about "encapsulating the enduser request" inside the Redirection Request. I find this misleading, because this is not about encapsulating the enduser request per-say, but rather to convey the key attributes of the enduser request.

* for HTTP, the Redirection Request should allow passing other attributes in addition to client IP address and URI.

* the document requires that a pointer to Metadata be included in the Redirection request:
"For DNS redirection, the uCDN also needs to provide in the CDNI RRRI
   request the a link to the associated CDNI Metadata for the host/
   domain being requested."
Considering that the latest Metadata interface allows the dCDN to walk down the metadata tree for any content without seeding any initial info/pointers, I am not sure there is a benefit in passing a link to metadata inside the Redirection request. If would potentially save the dCDN Request Router to do the lookup on Content-->Metadata , but would require the uCDN Request Router to do the same on its behalf. Besides the dCDN has to do that looup anyways to get the Metadata for serving the content.

* the redirection interface will need to discuss handling of URI Signing 

* we need to agree on a set of acronyms to refer to the "CDNI Request Routing/Redirection Interface". I will bring that up during the meeting this week.

HTH

Francois

On 21 Oct 2012, at 23:02, <[email-masked]>
 <[email-masked]> wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Routing Request Redirection for CDN Interconnection
> 	Author(s)       : Wang Danhua (editor)
>                          He Xiaoyan
>                          Spencer Dawkins
>                          Ge Chen
>                          Ni Wei
>                          Zhang Yunfei
>                          Ben Niven-Jenkins
> 	Filename        : draft-he-cdni-routing-request-redirection-03.txt
> 	Pages           : 19
> 	Date            : 2012-10-21
> 
> Abstract:
>   The Request Routing Interface comprises of (1) the asynchronous
>   advertisement of footprint and capabilities by a downstream CDN that
>   allows a upstream CDN to decide whether to redirect particular user
>   requests to that downstream CDN; and (2) the synchronous operation of
>   an upstream CDN requesting whether a downstream CDN is prepared to
>   accept a user request and of a downstream CDN responding with how to
>   actually redirect the user request.  This document describes an
>   interface for the latter part, i.e. the CDNI Request Routing
>   Redirection interface.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirection
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-03
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-he-cdni-routing-request-redirection-03
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> 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: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 6 Nov 2012 15:25:14 +0000

Francois,

Please see below for my views.

> You could possibly mention one of the behavior above as an example of what might happen, but it should just be an example and I recommend the spec be open as to the logic to populate the Redirectio…

Fair comment. Describing the different redirection possibilities & their applicability while at the same time talking about CDNI Redirection in a more generic way (so we don't keep repeating all the different nuances) was something we struggled a little with and is certainly an area of the draft (IMO) that needs more work to make the text clearer etc.

I like your idea of a 'redirection target' and maybe the right approach is to have a section defining/discussing the possibilities for redirection (A/AAAA/CNAME/Application level 302/etc) to a 'redirection target' in a dCDN and in the rest of the document just talk generically about redirection targets?
  
> * the document keeps talking about "encapsulating the enduser request" inside the Redirection Request. I find this misleading, because this is not about encapsulating the enduser request per-say, b…

Fair comment. We used 'encapsulating end user request' to distinguish between previous versions of the draft where the end user request was proxied to a dCDN via the same protocol that the end user request was made over.

Going forward that history doesn't matter and we should use better language to describe what we are actually doing.
 
> * for HTTP, the Redirection Request should allow passing other attributes in addition to client IP address and URI.

The draft currently just tries to define the minimum necessary information for a dCDN to be able to perform a redirection. There are probably other attributes that the dCDN would find useful and although it is not explicitly described in the current draft I think the CDNI Redirection 'protocol framework' in draft-he easily allows passing additional optional attributes. Describing how to extend the 'base protocol' with additional attributes is certainly something we should add in a future revision of the draft.

Personally, I am reluctant to define lots of theoretical attributes (that no one ends up using) to be included in a CDN Redirection request but I would like to hear views from implementors on the attributes they actually use (or plan to use as part of CDNI) to influence surrogate selection/redirection across a CDN interconnect.

> Considering that the latest Metadata interface allows the dCDN to walk down the metadata tree for any content without seeding any initial info/pointers, I am not sure there is a benefit in passing…

This is in my slides for Thursday. When I was thinking about CDN Redirection a while ago I convinced myself a link to CDNI Metadata was useful so when I started working on draft-he I included it, but since then I've been struggling to remind myself why I originally thought it was required so I'm certainly open to removing it.

> * the redirection interface will need to discuss handling of URI Signing 

Sure. Personally I'd like the uri signing/token authorisation work in the WG to mature a bit more first just to avoid having to keep draft-he aligned with a still moving target.

At a minimum we should include in the next revision a comment that we still need to factor token authorisation into the document.

> * we need to agree on a set of acronyms to refer to the "CDNI Request Routing/Redirection Interface". I will bring that up during the meeting this week.

OK

Ben

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 7 Nov 2012 14:32:02 +0000

Thanks for your responses. Looks like we're synch. Please keep track of those points so they get addressed in the next rev.
You may want to bring up some of those today (e.g. need for link to metadata in Redirection request) , specifically during the "discussion slot" for Redirection, so we get input from others.