[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments for WG Last Call: draft-ietf-cdi-known-request-routing-00.txt
> This is a CDI Working Group Last Call for comments on
> draft-ietf-cdi-known-request-routing-00.txt
>
> This last call closes April 20 2002 (*). Please post any final comments you
> have on the draft to this list by that date. If there are no substantive
> technical issues raised by April 20, we will forward this document to the
> IESG for publication as
> Informational.
Here are a few comments, presented on lines prefixed by ">>>", as Philr did.
Known CN Request-Routing Mechanisms
draft-ietf-cdi-known-request-routing-00.txt
[...]
1. Introduction
>>> Too many spaces...
The document provides a summary of current known techniques that
could be used to direct client requests to surrogates based on
various policies and a possible set of metrics. The task of
directing clients' requests to surrogates is also called
Request-Routing, Content Routing or Content Redirection.
Request-Routing techniques are commonly used in Content Networks
(also known as Content Delivery Networks)[5]. Content Networks
include network infrastructure that exists in layers 4 through 7.
Content Networks deal with the routing and forwarding of requests
and responses for content. Content Networks rely on layer 7
protocols such as HTTP [4] OR RTP [8] for transport.
>>> This sentence seems to imply that RTP is a layer 7 protocol! But also
>>> look on my comment about SSL in section 4.1.
Request-Routing techniques are generally used to direct client
requests for objects to a surrogate or a set of surrogates that
could best serve that content. Request-Routing mechanisms could
be used to direct client requests to surrogates that are within a
Content Network (CN) [5].
Request-Routing techniques are used as a vehicle to extend the
reach and scale of Content Delivery Networks. There exist multiple
>>> I don't understand this "extending the reach and scale" sentence. I
>>> would link that to CDN peering (sorry, internetworking :), not RR in
>>> general...
[...]
2.1 Single Reply
In this approach, the DNS server is authoritative for the entire
DNS domain or a sub domain. The DNS server returns the IP address
of the best surrogate in an A record to the requesting DNS server.
>>> It's easy to get confused between the different kinds of DNS servers. I
>>> personnaly use the terms "DNS server" for a server that owns a part of
>>> the database and "DNS resolver" (which is called requesting DNS server
>>> in the draft) for a server that doesn't own a part of the database but
>>> just provides the resolution service (by accepting recursive
>>> queries). The actual client application is linked with a "stub
>>> resolver". One could argue that the same machine can do both things, but
>>> this is still two different fonctionnalities, so a machine can be both a
>>> DNS server and a DNS resolver. This is how I understand page 7 of
>>> RFC1035, except the "DNS resolver" is called a "recursive server" there.
[...]
2.4 Anycast
>>> What's the relation between anycast and the DNS (section 2 is about DNS
>>> based RR techinques)?
[...]
2.6 DNS Request-Routing Limitations
[...]
3. Some DNS implementations do not always adhere to DNS standards.
For example, many DNS implementations do not honor the DNS TTL
field.
>>> I know of this problem only for applications (i.e. the client side of
>>> DNS). I suggest: "Some client DNS implementations do not conform
>>> entirely to the DNS standards."
4. DNS Request-Routing is based only on knowledge of the client
DNS server, as client addresses are not relayed within DNS
requests. This limits the ability of the Request-Routing system
to determine a client's proximity to the surrogate.
5. DNS servers can request and allow recursive resolution of DNS
names. For recursive resolution of requests, the Request-
Routing DNS server will not be exposed to the IP address of the
>>> I may be wrong as I'm not a native english speaker, but I would build
>>> the sentence the reverse way: "The IP address of the client... would not
>>> be exposed to the RR DNS server". Am I wrong in believing that "I am
>>> exposed to" means "I can be seen by" rather than "I can see that..."?
client's site DNS server. In this case, the Request-Routing DNS
server will be exposed to the address of the DNS server that is
>>> Same as above.
[...]
4.1 Header Inspection
Applications such as HTTP [4], RTSP [3], and SSL [2] provide hints
>>> I may sound quibbling, but I would call HTTP and RTSP application level
>>> protocols rather than applications. As for SSL, [2] describes
>>> "Transport Layer Security" which doesn't sound "application". I guess
>>> that "application" in this document is to be understood as anything
>>> that's above the Internet standard transport protocols, TCP and UDP. If
>>> this is the case, this should probably be stated more explicitly
>>> (probably early in the document).
in the initial portion of the session about how the client request
must be directed. These hints may come from the URL of the content
or other parts of the MIME request header such as Cookies.
4.1.1 URL-Based Request-Routing
A Uniform Resource Locator (URL) [7] consists of a naming scheme
followed by a string whose format is a function of the naming
scheme. The string must start with a constant prefix "URL:".
>>> What? Here is what [7] says:
>APPENDIX: Recommendations for URLs in Context
>
> URIs, including URLs, are intended to be transmitted through
> protocols which provide a context for their interpretation.
>
> In some cases, it will be necessary to distinguish URLs from other
> possible data structures in a syntactic structure. In this case, is
> recommended that URLs be preceeded with a prefix consisting of the
> characters "URL:". For example, this prefix may be used to
> distinguish URLs from other kinds of URIs.
>>> So the sentence "The string must..." is false (the "URL:" prefix is to
>>> be placed before the URL, not between the scheme and "string".) Anyway,
>>> this "recommandation" is only for identifying URLs in certain contexts,
>>> so there's no point in talking about this here.
[...]
4.1.1.2 In-Path Element
[...]
The technique allows for the possibility of portioning the traffic
>>> pArtitioning
among a set of delivery nodes by content objects identified by URLs.
This allows object-specific control of server loading. For example,
requests for non-cacheable object types may be directed away from a
cache.
4.1.2 Mime Header-Based Request-Routing
This technique involves the task of using MIME-headers such as
Cookie, Language, and User-Agent, in order to select a surrogate.
Cookies can be used to identify a customer or session by a web site.
Cookie based Request-Routing provides content service
differentiation based on the client. This approach works provided
that the cookies belong to the client. In addition, it is possible
to direct a connection from a multi-session transaction to be
>>> I don't like the expression "multi-session transaction" (I feel a
>>> session is something longer than a transaction) though I think I
>>> understand what is meant.
directed to the same server to achieve session-level
persistence.
[...]
8. References
[...]
[5] Day, M., Cain, B. and G. Tomlinson, " A Model for Content
Internetworking (CDI)", http://www.ietf.org/internet-drafts/
draft-day-cdnp-model-09.txt (Group Last Call).
>>> This is the old name of the draft.
[6] Partridge, C., Mendez, T., Milliken W., "Host Anycasting
Service", RFC 1546, November 1993.
[7] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource
Locator (URL), RFC 1738,May 1994.
>>> LocatorS -- space typos
[...]
A.1.1 Active Probing
Active probing is when past or possible requesting entities are
probed using one or more techniques to determine one or more
>>> One can also probe a machine that's not a requesting entity but a
>>> machine representing a set of requesting entities. E.g. the last router
>>> before a NAT firewall represents all the clients behind the firewall.
metrics from each surrogate or set of surrogates. An example of
a probing technique is an ICMP ECHO Request that is periodically
sent from each surrogate or set of surrogates to a potential
requesting entity.
In any active probing approach, a list of potential requesting
entities need to be obtained. This list can be generated
dynamically. Here, as requests arrive, the requesting entity
addresses can be cached for later probing. Another potential
solution is to use an algorithm to divide address space into blocks
and to probe random addresses within those blocks. Limitations
of active probing techniques include:
1. Measurements can only be taken periodically.
2. Firewalls and NATs disallow probes.
>>> See previous comment.
[...]
A.1.3 Metric Types
The following sections list some of the metrics, which can be used
for proximity calculations.
>>> sections? I suggest "Here is a list of some of the metrics which can be
>>> used for proximity calculations."
[...]
--
(°- Christophe Deleuze, PhD Christophe.Deleuze@ActiVia.net
//\ R&D Senior Engineer tel/fax (+33) 4 97 23 46 58/47
v_/_ ActiVia Networks http://www.activia.net