Comments on Request Routing Requirements

[DonE@activate.net]

>From my point of view, for Content Interworking to be a reality Request
Routing Peering is by far the highest priority because there is no other way
to direct requests to the best CDN.  The next priority is Accounting Peering
because frequent retrieval of accounting data is a hassle, and, at least for
infrequently changing content, Distribution Peering is needed much less
often.

So I don't understand why there hasn't been more discussion on this list of
the Request Routing Requirements drafts (last two versions were posted on
1/22/01 and 3/2/01).  There are probably several reasons, but I assume there
is still interest in Content Interworking beyond proprietary solutions.

Don Estberg


Comments on Request Routing Requirements

General

Overall the document has made significant progress, and is close to being
ready.

I think the organization of the 1/22 version with the background text
grouped with the requirements makes understanding of the intent of the
specific requirements easier.

P. 3, Section 1.3, Item 2

Since the Content Topology Database contains data to allow Routing
Computation, I would think it would contain data about itself as a CDN in
addition to data "received from neighbors".

P. 3, Section 1.3, Item 4 (first occurrence)

One responsibility of the Distribution Peering System is replication of
content to appropriate CDNs, so this should be the source of information on
availability of content, rather than the Request Routing having its own
content advertisement protocol.  Since this is a rather basic assumption for
Request Routing, if I may be missing something here, the reason for the
existence of content advertisement needs to be explained.

P. 5, Section 2.1.1, 3rd Paragraph

clients DNS resolution -> client's DNS resolution

Also I never got an answer to my previous posting asking what is the
disadvantage of removing the main drawback to DNS-based request routing by
setting up specific domain names to identify content.

P. 5, Section 2.1.1.1, 1st Paragraph (first occurrence)

Instead of "area", in other CDI documents, the more descriptive term
"footprint" is used.

Pages 5 - 6, Section 2.1.2, 1st Paragraph

As mentioned in a previous posting, layer-7/proxy request routing that is
"close to a client" should be distinguished from origin server
URL-rewriting.  The term "in-line" may not be appropriate for the latter,
since the client's browser deals with the rewritten URL.  Actually, this is
no big deal and it probably easier to keep these grouped together, but the
wording should be improved.  Also, this is clearly covered on P. 10, Section
3.2.2, 1st Item.

P. 7, Section 2.2, 2nd Paragraph

Using the term "next-best" is misleading, since from the point of view of
that CDN it is determining the "best", which may be itself.  The wording in
previous version (P. 5, Section 2.1, 1st paragraph) was clearer.

P. 7, Sections 2.3 and 2.4

As mentioned before, the Distribution System can be the source of
information that describes the content.

P. 7, Section 2.4, 1st paragraph

"section 1.2" -> "section 2.1"

P. 7, Section 2.4, Item 1

Am I correct in assuming that information about current load of surrogates
in a CDN would be part of this information?

P. 9, Section 3.1, 3rd Item

I vote for "MUST".

P. 9, Section 3.1, 4th Item

"direction request" -> "request-routing request"

P. 9, Section 3.1, 5th Item

"avoid violation of" -> "not violate"

Also, add a reference.

P. 9, Section 3.2, 1st Item

I think this should be "SHOULD".  It may turn out that one or the other is
the way to go; the need for both is not obvious to me anyway.

P. 9, Section 3.2, 2nd Item

I don't understand what "at least one common type" refers to.

P. 9, Section 3.2, 3rd Item

What is "their request-routing type"?  Is it whether a CDN's internal
request routing is DNS-based or in-line?  If so, I don't think should be
required to communicate this, so change the MUST to MAY.

P. 9, Section 3.2, 5th Item and P. 10, Section 3.2.1, 3rd Item

The 5th item in Section 3.2 seems entirely a DNS-based item, so should only
be in Section 3.2.1; in fact, it is similar to the 3rd item in Section
3.2.1.

I vote this item be kept as SHOULD.

P. 10, Section 3.2.2, 1st Item

"this methods" -> "this method"

P. 10, Section 3.2.2, 2nd Item

"todays Internet" -> "today's Internet"

This possibly could be SHOULD, but it is an important point, so I would
leave it as MUST.

P. 10, Section 3.3

I think this should be "SHOULD", unless there is something I'm missing.

P. 11, Section 3.5.1, 2nd Item and Section 3.5.2, 1st Item

Using the terms "layer-3 coverage" and "IP prefixes" alludes to a way of
defining the footprint of a CDN's surrogates, but the difficulty and
alternatives needs to be discussed in more detail in this requirements
document (as it has been to some extent on this list).

P. 11, Section 3.5.2, 4th through 8th Items

Again, CONTENT UNIT advertisements should belong to the Distribution System.

P. 12, Section 3.6, 2nd Item

The term "guarantee" seems too strong.  How about requiring that the
decision give the best probability of delivery based on the agreed-upon
metric?

P. 12, Section 3.6, 4th  Item

"direction decision" -> "request-routing decision"

P. 13, Section 3.7, 4th Item

"RRP station" -> "request-routing CPG"

P. 13, Section 3.7, 6th Item

I'm not sure what "neighbor discovery" is, but I don't think it should be
part of the protocol, at least for now.

P. 13, Section 3.7, 9th Item

Typo:  I believe the word "provide" should be omitted.