RE: hard questions: request routing

[Oliver Spatscheck <spatsch@research.att.com>]

I do not think this architecture has been discarded at all. I think we
only recognized that sometimes CDN B wants to have real time control
over which surrogate is used and also does not want to provide a
list of all currently available surrogates to A. 

So I think we have to support both. 

As for your solution outlined below in step 2. you can still get
loops. However, they are easily removed by adding a path to each
request for resolution which we can do since the protocol
between RR A and RR B is defined by us (so we don't need an ugly
DNS hack ....).

Oliver


MITTIG Karel FTRD/DMI/CAE writes:
 > 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 ?
 >