Questions/issues about Request-Routing Requirements

[DonE@activate.net]

I don’t think we’re at a stage yet for detailed comments on “Request
Routing Requirements for Content Interworking”, but instead I want to ask
4 general questions / raise  4 general issues that I don’t understand:

1.  Although confusion between Distribution and Request Routing has
been discussed on this list several times, some of the needs for
advertisement in the RR rqmts raised it for me again.  Is the reason
because,
in the case of pull-type distribution, the distribution may be done at
request-
routing time?  If so, maybe the protocol split should be
    + A protocol only needed by distribution
    + A protocol only needed by request routing
    + A protocol used by distribution and request routing.
This last protocol would be specified by most of the requirements in
Subsection 3.2.2 (Advertisement) of the RR rqmts.

2.  As I read the section in the RR rqmts about DNS-based RR, I kept
wondering why not set up specific domain names to identify content, but
then I learned that in fact it is done:

At 5:56 AM 2001-01-30, Oliver Spatscheck wrote:

> I agree that requireing to seperate content by domain name if
> DNS based RSS are used is an ugly hack (which happens to be
> used by nearly all CDNs...) but I think it will be the most
> liekly candidate of beeing adopted in the short term.

I don’t know the status of standardizing the various proposed extensions
for DNS beyond its original purpose, but I thought approach of the IETF
was to accept change as long as it did no harm.  So the question is
whether this WG considers using domain names to separate content to
useful enough to recognize?

3.  In the beginning of the RR rqmts where routing system types are first
discussed, using an origin server for redirection is grouped with other
Layer-7 methods.  But these other methods (using a proxy and using a
Layer-7 router) generally happen on the edge, so have quite different
capabilities than using an origin server.  In fact, using an origin server
is
more like using DNS-based methods, so it can be used to create a global
RRS by combining CDNs, especially for streaming content.  Any objection
to giving the origin-server method more prominence?

4.  I’m very much in favor of using RRS internetworking, but in a pinch it
can also be done off-line, but still take advantage of distribution and
accounting CDI. Just to make sure, could there be a requirement that the
distribution or accounting protocols would not require use of the RRP?

Those are my questions, but here are a couple of other comments from the
list that I think are worth including in the RR rqmts:

At  7:10 PM 2001-01-25, Dmitri Krioukaov wrote:

> Interconnected RRSs perform the function
> of one global RRS. The function of *any*
> RRS is to intelligently map the {client
> IP address (prefix), URI} duplex to an ID
> (which boils down to an IP address) of some
> surrogate from the set of surrogates capable
> of processing request for that URI.
> "Intelligently" means that the minimal
> metric (which is a function of all three --
> client, URI and surrogate) is searched for.

At 5:39 AM 2001-01-26, Oliver Spatscheck wrote:

> Maybe it didn't become
> clear in the draft. I think the consensus was to require a minimal
> set of metrics say one and to allow for custom metrics which
> are on a peer to peer basis.

At 7:40 PM 2001-01-20, brad cain wrote:

> > It's also easy to name it if we take into consideration that
> > the final goal is fastest response.

> I don't think so... simple example: delay or throughput
[and therefore “best” was used in the RR rqmts]

At 7:54 PM 2001-01-30, brad cain wrote:

> However, CDNs are a bit different because:
> 	1. they are overlay networks which
> 	2. means that most request routing systems will only be peered in
> 	a two level hierarchy -- to do more doesn't make any sense
> 	3. most requests should resolve in one or two request routing
> 	hops …

Thanks,
Don Estberg