Executive summary of: RE: hard questions: request routing

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

Enclosed the executive summary of the discussion about loop avoidance in
request routing. I think I finally understood Abbie's solution after talking
to him and we think it is time that the group agrees which method we should use
to move on. The candidates which crystallized so far:


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.

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.

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).

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 think we discarded already the path vector with common metric
approach. So at this point we have to decide which way we want
to go. PLEASE VOTE NOW!

Oliver