RE: Executive summary of: RE: hard questions: request routing

["Cain, Brad" <bcain@cereva.com>]

> 1. Restrict the topology.
> 
>    This solution statically restricts the depth of request 
> routing to one (or
>    maybe two). This avoids loops due to its static 
> limitation, however, it is
>    the most restrictive one. On the other hand the protcol 
> overhead is zero.

I think this is reasonable for the short term because:
	1. request routing will not span more than one
	level because of business relationships (e.g. content
	providers will want some amount of control over which
	cdns distribute their content)
	2. request routing (and cdns in general) are overlays
	which will allow arbitrary interconnections
	3. we don't yet know how this will turn out and its
	the most simple solution


> 2. Recursive request routing
> 
>    The request is handled by the first CDN contacted by a 
> client.  The CDN
>    will ask other CDN's recursively to resolve to an A 
> record.  This recursive
>    request includes a request path which can be used to 
> prevent loops. This
>    avoids the DNS hack issue, however, it requires a new 
> protocol (or DNS
>    extension) to carry the path information.

i think a L2/L3 analogy can be drawn here... that is, circuit
setup with distributed topology information.  for example,
in many circuit networks, circuits are setup by each hop
making an independent decision and laying the path as
the request moves (e.g. rsvp)... the only difference here is
that the final circuit (e.g. the set of hops) is returned
to the originator so that the final hop can be returned
(and of course intermediate state isn't kept)


> 3. Abbie's proposal
> 
>    A matrix is distributed to all participants representing 
> the relationships
>    between individual CDNs for a particular set of content.  
> This matrix is
>    used to encode the path info as set of CNAMEs in a 
> structured way. So this
>    solution is similar to Brad's suggestion, except it adds 
> structure to the
>    CNAME encoding (see Abbie's email for more data).

actually, isn't this similar in concept to #2
 
> 4. Abbie's proposal as I understood it first..... .
> 
>    A cycle free graph is generated based on the matrix every 
> time a CDN starts
>    or stops serving a particular set of content. This cycle 
> free graph is
>    distributed to all CDN's involved atomically. Request 
> routing is now a
>    traversal of this cycle free graph. This is basically a 
> variant of a link
>    state protocol, but the atomic requirement makes it rather 
> expensive.

i assume that the authoritative CDN makes all decisions (based
on the link state information)?  #1 would be the degenerate case?


i guess we need to make a decision at an abstract level which is:

should the authoritative request routing CDN always make the
final decision or should it be allowed to "hand-off" the
decision?  if the decision is centralized then it makes the
problem fairly easy... you could make a strong argument for
centralized decisions due to the business relationships in
content distribution.. furthermore you can make an argument
that routing the request introduces too much delay and that
the authoritative domain should make the decision


i propose a 5th solution which is:

	- topology advertisements are distributed/flooded in a loop
	free manner
	- routing decisions are NOT SPECIFIED.  in the common case the
	authoritative domain makes the final decision with all of the
	topology information ( = easy loop freedom!)
	- requests that are routed to another CDN must not be
	routed further (ie. restricted two-level hierarchy)
	- recursion isn't supported (yet) because we need a circuit
	signaling type protocol

-brad