Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt

[hardie@equinix.com]

Gunnar,
	Some notes in-line; sorry for my own delay in
replying.
			Ted

> 
> >From owner-dnsop@cafax.se  Wed Sep  8 19:16:16 1999
> >Date: Wed, 8 Sep 1999 10:15:31 -0700 (PDT)
> >From: Jerry Scharf <scharf@vix.com>
> >To: Gunnar Lindberg <lindberg@cdg.chalmers.se>
> >cc: dnsop@cafax.se
> >Subject: Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt
> >Message-ID: <Pine.BSI.4.05L.9909081008210.1551-100000@sh.lh.vix.com>
> 
> >On Wed, 8 Sep 1999, Gunnar Lindberg wrote:
> 
> >> Ted,
> >> 
> >> Sorry for the long delay, but I had hoped someone else would step in.
> >> 
> >> Anyway, it seems to me we agree on what can be agreed on, given rather
> >> different proposals. Sometime in the future the WG will make some
> >> decision, I guess.
> >> 
> >> Finally, a comment on "anycast" that I haven't seen yet (but which
> >> may have been beaten to death before I joined the list). What about:
> >> 
> >>     "anycast"
> >>     "TCP lookup" (lookup - not AXFR)
> >>     "equal-cost multi-path, per-packet, load sharing"
> >> 
> >> E.g: at some site they have two equal-cost routes to [198.41.0.4]. We
> >> know it's anycast - routes to *different instances* of [198.41.0.4]
> >> and not two routes to the same host - but the routers don't. Instead
> >> the routers send 50% of the packets one direction and 50% the other.
> >> 
> >> No big deal for UDP queries that are self contained, but TCP has a
> >> connection and keeps state and 50% TCP packets to each [198.41.0.4]
> >> instance is not likely to work. And, at least for UNIX the choice of
> >> UDP or TCP is set per application, "_res.options |= RES_USEVC", which
> >> is hard enough to handle - what BillGatesWare does is unknown to me.
> >> 
> >> Am I the only person worried?
> >> 
> >> 	Gunnar

As you note, the situation with equal-cost routes to two different
instances doesn't effect UDP, which is a big chunk of the traffic to
the roots.  It is a concern for TCP lookups, but only when you
have both equal cost routes and per-packet load sharing.  Note that
for ciscos, fast switching does per-destination load balancing rather
than per packet load balancing; fast switching is also on by default
and preferred for line speeds over 56 Kbps.  There are some cisco
specific docs at:

http://cco.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2003.htm#xtocid133834

that describe their behavior.

Of course, ciscos aren't the only boxes in the world, and people do
turn fast switching off.  Two things additional factors mitigate the
severity of the problem.  The first is that the aim of this proposal
is to diversify the topological placement of the roots; for most users
that means that any "new" squiggle.root-servers.net will be a
significantly different cost metric from the "old"
squiggle.root-server.net, because it will be topologically distant
from the original.  Someone may end up in the middle, but that should
be rare if the primary aim is being followed.  Even in that case, any
implementation which measures the reponse performance of the roots to
select a preferred server will quickly drop that server; performance
might subsequently degrade for its users, but the system should still
work.  So even for users who do happen to be
equal-cost-routing/per-packet-load-sharing/tcp-using kind of folks,
the DNS will still work.

> >There are ways of doing load sharing that do not screw up TCP
> >(Cisco CEF
> >being one example.) If someone is using routing tricks, we have
> >to require
> >them to not be stupid about how to do that. I think you could add
> >language
> >that points out to the person implementing anycast routing that
> >this kind
> >of situation must be avoided.
> 
> The sad news is that it's not the person implementing anycast routing
> who gets hit, but the persons that already have unicast routing up
> running (most of us :-), and happened to end up with multiple paths.
> I'm not sure it's convinient that the IETF comes up with a "use Cisco
> CEF" recommendation to them.
> 
> >I don't see it as a specific reason to toss the concept out of hand.
> >It is
> >a risk and needs to be evaluated against benefits.
> 
> Agree 100% on the latter.
> 
> 	Gunnar

As you both note, it's a risk vs. benefit evaluation.  For something
which is largely UDP, a correct implementation of this scheme should
have a pretty good rewards to risks ratio.  I also don't believe that
there is any case in which implementing this will cause the *overall*
system to fail; at worst, it seems that some number of users might
have degraded performance in the face of certain routing conditions.
If the placement was right and traffic patterns remain as they are,
that number should be pretty small.*
			regards,
				Ted





*Your mileage may vary.  Offer void in Missouri, Quebec, and wherever
prohibited by law.  Standard disclaimers apply.  Asses should be
covered before buckshot fired.