Skip to main content

Known Content Network (CN) Request-Routing Mechanisms

Revision differences

Document history

Date Rev. By Action
03 (System) Ballot writeup text was added
03 (System) Ballot approval text was added
03 Natalia Syracuse State Changes to RFC Ed Queue from Approved-announcement sent by Syracuse, Natalia
03 Jacqueline Hargest State Changes to Approved-announcement sent from Approved-announcement to be sent by Hargest, Jacqueline
03 Ted Hardie New version has cleared issues raised
03 Ted Hardie State Changes to Approved-announcement to be sent from IESG Evaluation  :: Revised ID Needed by Hardie, Ted
03 (System) IESG has approved the document
03 (System) New version available: draft-ietf-cdi-known-request-routing-03.txt
03 Ted Hardie Shepherding AD has been changed to Hardie, Ted from Faltstrom, Patrik
03 Patrik Fältström
From Ops Directorate:


Given the extensive research that has been done in this
area, I am disappointed that there is not one citation to …
From Ops Directorate:


Given the extensive research that has been done in this
area, I am disappointed that there is not one citation to
the research within the reference section. Isn't at least
some of this material relevant to the subject? The
document doesn't even cite some relevant RFCs.

While there is some discussion of the limitations
of the DNS approach, there is no such discussion of
the issues relating to use of BGP AS-PATH or MED
metrics. Since this is a major technique, yet
doesn't work well in practice, I would expect
more discussion on this.

Overall, given that this is not a literature review, or
even an in-depth critical examination of the subject, I
am not clear about the value of this document to the
IETF community. Overall, it reads much more like a
summary of vendor marketing materials than a solid technical

Section 1.

Something should be said about how metrics are matched
to the application. There has been a substantial amount
of research in this area, showing benefits of various
strategies. Perhaps this research could be cited?
So what should we care about and when?

Section 2.

DNS is not a "directory service".

Section 2.2

RFC 2782 (DNS SRV) provides guidance relating to the use of DNS for
load balancing. For example:

"Weight, the server selection field, is not quite satisfactory, but
  the actual load on typical servers changes much too quickly to be
  kept around in DNS caches."


"For short-lived services an extra step in the
  connection establishment seems too expensive, and for long-lived
  services, the load figure may well be thrown off a minute after the
  connection is established when someone else starts or finishes a
  heavy job."


"Note: There are currently various experiments at providing relative
  network proximity estimation, available bandwidth estimation, and
  similar services.  Use of the SRV record with such facilities, and in
  particular the interpretation of the Weight field when these
  facilities are used, is for further study."

also a warning (that applies to any use of DNS for load balancing,
not just DNS SRV):

  "Using SRV weight for
  dynamic server selection would require assigning unreasonably short
  TTLs to the SRV RRs, which would limit the usefulness of the DNS
  caching mechanism, thus increasing overall network load and
  decreasing overall reliability."

So not only does this document ignore the warning, but there isn't even
a citation of the "further study" that might justify that. There is now
a *lot* of research on performance of the DNS system, so a review of
that literature doesn't seem unreasonable to me.

Section 2.6

The issue is not just that these techniques "may increase the volume
of requests to DNS servers". If the volume were only increased to the
authoritative servers who presumably were running the CDI service, then
presumably they could pay for more bandwidth. The problem is that the
load is also increased on third party DNS servers whose caches are
no longer effective. Increasing your own costs is one thing; increasing
someone else's costs without their approval is another thing.

The issue isn't that DNS servers can request and allow recursive
resolution. That's part of the DNS design and is not something we
need to "fix". The issue is that "stub resolvers" don't support
recursion themselves -- and therefore unless they are modified,
the request will typically appear to come from the local DNS server.

I would also like to see more discussion of the limitations described
in RFC 2782.

Overall, these limitations are just treated as a list of minor drawbacks.
Creating scaling problems within the DNS, in order to optimize
proximity to the local DNS server which may not be remotely near the
client you're trying to help, does not seem like a good idea to

Section 3

"The techniques that are used to hand off the session to a more
appropriate surrogate are beyond the scope"

Can't we at least have a citation to documents in which this is

"In general, the forward-flow traffic... will flow through the
surrogate...reverse-flow traffic flows.. would typically take
the direct path"

If we're talking about transport-layer load balancing, isn't TCP
sequence no. translation being implemented in both directions?
Couldn't we have at least a cursory discussion of this, or if not
that, some citations?

"The overhead associated with..."

Overall, the document could do with more discussion of overhead. As noted
in RFC 2782, the overhead issue applies to more than just Transport layer
load balancing techniques. Any short-lived flow could have this problem
with other techniques, too.


Some more detail about elements of the headers used for routing would
be appropriate. Can the document say a few words about what these are
for different protocols (e.g. SSL/TLS)?

4.2.3 Content modification limitations

This section seems more than a little skimpy. After all the discussion
we've had in IETF on this topic, the draft could only come up with
a single paragraph?

Section 6

The security considerations section is only two
paragraphs, one of which says that security
techniques are beyond the scope.

Given that some of the techniques (active probing)
set off intrusion systems and firewalls, and others
require adding a participant within the routing mesh, it would
seem like more discussion is appropriate. For example,
there could be some citation of routing protocol security.

Appendix A.1

If "proximity" means round-trip time, then this
section should say this. Otherwise, I'm not sure
what "proximity" means. TTL? RTT?

The problem of course is that "proximity to the
client's local DNS server" is a poor surrogate for
"proximity to the client". Many ISPs operate DNS
servers quite far from potential clients and so
the DNS server is frequently half a continent
away from the client. This means that his metric,
like others (BGP AS-Path) is frequently meaningless.


How about adding as another liability:
The traffic generated from Active Probing is of the
same order as the DNS traffic.


Why is "packet loss" being cited as a measure of
"proximity" here? Yes, TCP can provide RTT measurements,
but typically only on the sender side. The "surrogate"
is typically a receiver, no? This section should say
something about how this is supposed to work and cite
research to show why it is valid.


What kind of delay is being measured and why? Are we talking
about RTTmin? RTTmax?

Again, why is "Packet Loss" being used as a measure
of proximity?

If Hop Counts are being cited as a proximity measurement,
where is the citation to the research that supports this

BGP AS PATH and MED attributes are a notoriously terrible
measure of proximity. For example, within North America
most ISPs are within 2 BGP ASes from each other, no matter
how geographically distant they might be. So this metric
is virtually worthless.


There is quite a bit of research work in this area, such as
within Ellen Zegura's group at Georgia Tech. Couldn't some
of this work have been cited?


Some discussion about the drawbacks of these metrics is
appropriate. For example, CPU load is a dangerous metric
to use since it will funnel traffic to systems that are
malfunctioning. This metric also tends to result in
instability, without appropriate damping (similar to
effects seen in dynamic OSPF load balancing). Again,
some citation of the literature seems appropriate.
03 Patrik Fältström
Comment from Steve Bellovin:

The security considerations section really should note the impact of
TLS on CNs.  In particular, if TLS is used the full …
Comment from Steve Bellovin:

The security considerations section really should note the impact of
TLS on CNs.  In particular, if TLS is used the full URL is not visible
to the content network unless it terminates the TLS session; if it
does, it needs to have an appropriate certificate and private key. 
Similarly, all servers that may receive a rerouted request, by any
mechanism, must have such certificates and keys.
03 Patrik Fältström State Changes to IESG Evaluation  :: Revised ID Needed from IESG Evaluation by Faltstrom, Patrik
03 Patrik Fältström State Changes to IESG Evaluation from AD Evaluation  :: AD Followup by Faltstrom, Patrik
03 Patrik Fältström New version include changes requested by AD which reviewed the document.
03 Patrik Fältström State Changes to AD Evaluation  :: AD Followup from Publication Requested by Faltstrom, Patrik
02 (System) New version available: draft-ietf-cdi-known-request-routing-02.txt
03 Patrik Fältström Intended Status has been changed to Informational from None
03 Stephen Coya Draft Added by scoya
01 (System) New version available: draft-ietf-cdi-known-request-routing-01.txt
00 (System) New version available: draft-ietf-cdi-known-request-routing-00.txt