[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on Request Routing Requirements
Don,
Good comments. I agree, I do think that the majority of interactions
between two consumer facing CDNs would require a very clear, functional and
scalable RRS. But what about a third party vendor that brings a clearing
house type of solution to multiple CDN peers? In this case I think the
interactions between the consumer facing CDN and the Clearing house would
be much more dependant on the Accounting systems. A peering between a
Content provider's network or a transit network with large hosting
agreements with content providers would of course prioritize the
distribution system. I would be willing to bet that there will be more
consumer facing CDNs in the market than the clearing house or hosing /
transit types, however I think it important not to prioritize one system
over the other in this standards effort. I think the business applications
will force a prioritization based on individual implementations.
Also, its my feeling that the business problems surrounding peering are much
more difficult nuts to crack than the technical.
Regards,
Paul Scanlon
-----Original Message-----
From: DonE@activate.net [mailto:DonE@activate.net]
Sent: Monday, March 12, 2001 6:20 PM
To: cdn@ops.ietf.org
Subject: Comments on Request Routing Requirements
>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.