Re: hard questions: request routing

[Francis Zane <francis@research.bell-labs.com>]

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

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

More later,

Francis Zane