RE: hard questions: request routing

[MITTIG Karel FTRD/DMI/CAE <karel.mittig@rd.francetelecom.fr>]

Hello,

All the messages I've seen are only dealing with hierarchical RRs peering, 
using delegation (CNAME, NS, URL rewriting,...) and/or forwarding, right ?

For me, another way could be to use a horizontal collaboration: instead of 
delegating the routing mechanism to another CDN, it consists in asking other

CDNs for metrics, while the routing decision remains to content owner CDN. 
In order to do this, other RRs are seen by first RR just as black-box
agents.


If I take an example with 2 DNS based RRs, A and B. CDN A has a content
defined
by www.site.com, which it wants to peer with CDN B. Because A owns the
content,
it might want to remain authoritative on it, because it's him who is
responsible
of the end-user delivery (for the Content Provider point of view).

My opinion to do this is to have a dedicated protocol between RRs
Controllers, 
which is distinct from the routing mechanism. 

This protocol might looks like below:


1.Peering negotiation phase

RR A	<---------------------------------------------> RR B
	   metrics handled (RTT, server load, hops,...)

RR A	<---------------------------------------------> RR B
	   	TTLs accepted (minimum, maximum)

Eventually:
RR A	<---------------------------------------------> RR B
	   		peered URI()


2.First client request
Client 1 requests www.site.com
	|
	|
	\/
    RR A	-----------------------------------------------> RR B	
		         Metrics value (Client IP, URI)?
	|
	|
	\/
     RR A response to client : www.site.com , A surrogate IP 
     (acting just like it was alone)

(CDN B URI availability could be known using announcement)


3.(A)synchronous reply of B
RR A	<----------------------------------------------- RR B
	     Best response = corresponding surrogate IP 
		+ associated metrics values() 
		+ TTL for this response


For the RR A point of view:  	
  - does RR B manage given URI (may be done by announcement) ?
  - using A metrics algorithm, is the results given by B better than A ?
  - if true, A answers to next clients with B surrogate IP (and A refresh
metrics 
by calling B according to TTL)


4.Next requests
Client 1' requests www.site.com
	|
	|
	\/
     RR A (decide which between A surrogate or B surrogate is better ==>
find B)
	|
	|
	\/
RR A response to client : www.site.com , B surrogate IP 


Has this kind of architecture been discarded ? If so, why ?