Re: hard questions: request routing

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

Francis Zane writes:
 > 
 > I'm still working on getting caught up on the back issues, but let me
 > jump in on the current topic of loop-avoidance.  (Apologies in advance
 > for repeating past discussions and for slipping into non-approved
 > terminology.)
 > 
 > My argument for today:
 > 
 > * The details of the Request Routing mechanism matter
 > 
 > For some mechanisms (eg, DNS CNAME, HTTP redirect), lookups are
 > "forwardable" for lack of a better term, and can transfer state
 > (prepend my name to domain name to get path-vector, so I can check for
 > a loop on a per-lookup basis).

Brad suggested this solution, however, it seemed undesirable to 
add yet another hack to DNS..... .

 >  Some others (eg, forwarding by L4/L7
 > switch), are forwardable, but don't transfer state (at least not
 > easily).  Finally, others (eg, URL rewriting) aren't forwardable (and
 > so don't have forwarding loops).

And yet another problem is a system with a combination of L4/L7 switching,
URL rewriting and DNS redirection.

 > 
 > Question: Is the goal to have loop avoidance for all of these types of
 > mechanisms (well, the last are easy since they can't loop)?  If it's
 > just for DNS, then it can be embedded into the lookup protocol (more
 > on this in a second); if it's got to cover L4/7 forwarding, then it
 > can't (unless L7 forwarding is defined to require header adjustment).
 > 
 > The reason I ask is that transient loops are going to be harder to
 > take care of if the loop avoidance is in a separate mechanism.  Even
 > if the loop avoidance protocol works correctly, there will always be
 > asynchronies between the various Request Routers and gaps between the
 > loop-avoidance and redirection parts (which can be probably be solved,
 > but require more care).  On the other hand, if you require this state
 > transfer for a mechanism, it limits the space of mechanisms.
 > In addition, there seemed to be some concern about using these sorts
 > of state transference hacks in the redirection mechanism; if you
 > don't, though, then you're back to the same problem with transients.
 > 
 > If there are non-state-transfering RR mechanisms, or if using these
 > state-transfer hacks is deprecated, I think it be might easier simply
 > to make all mechanisms non-forwardable (eg, there are two classes of
 > DNS names, and compliant nameservers can only change class A into
 > class B, not vice versa).  It then becomes the responsibility of the
 > RRS (do I have that right?) to follow the chain of redirections to
 > come to a final answer.  Presumably this is done implicitly, by
 > reading over the set of announcements.
 > 
 > On reflection, this may be the right way to go, regardless, because it
 > treats all RR mechanisms uniformly.  This is similar in spirit to
 > Oliver's suggestion to limit the hierarchy depth.  But maybe there are
 > specific scenarios in mind that require deep forwarding hierarchies?
 > (If so, though, realize that URL rewriting is in trouble...)
 > 

Actually I thought a little bit more about it and you could allow
a depth of 3 without problems. First you classify all CDNs
in CDN's which further redirect (class 1) and CDNs which don't 
(class 2).

The rules would be:

    - every CDN in class 1 is allowed to redirect to every CDN in class 2
    - the authoritative CDN for a domain name can redirect this
      domain name to any class 1 and class 2 CDN
    Note: Since an authoritative CDN always redirects it is by
          definition in class 1.

This allows for redirection:

     authoritative CDN -> class 1 CDN -> class 2 CDN 

This classification with the two rules would avoid any loops in the
RRS no matter what method is used.

Oliver