ietf
[Top] [All Lists]

Re: [dnsop] Re: Root Anycast (fwd)

2004-10-01 11:27:13
Couple of points here.

1. Typical DNS queries are via UDP, not TCP.
   Thus the noise Dean is making here about things breaking
   because of TCP issues, is well  noise.

   Keep in mind that DNS queries are UDP.  The query and the response.
   so a typical query is 2 packets, the ask and the answer.

   Having DNS be based on TCP would NOT scale very well.  Think about
   it.  Before I could even make a query I would have to deal with
   at least 3 packets for the TCP connection setup.  Then I'd send my
   query, which would also have an TCP ACK sent as well, oh then there
   is the answer to the query, with yet another TCP ACK.  So a single
   DNS query would (at a min) take 7 packets, more likely 8 to 10,
   thats 400 to 500 percent more traffic than via UDP.

   DNS uses TCP in special cases. Some of them, but not all of them
   are.  1. Packet size, 2. AXFR, 3. I think TSIG / DNS SeC stuff

   Now before Dean jumps on the See, AXFR is broke, lets understand that
   AXFR doesn't happen for anycasted root servers on their PUBLIC facing
   IP address.  AXFR is typically going to happen on a globally unique
   IP assigned to each specific Anycast'd host.  Thus TCP works just
   fine.

2. This "single router requirement" is an interesting comment.  I've not
   seen this in any RFC or BCP.  Is there one ??  I'd hope not.

   Having muliple routers in a mesh format is good.  That means if one
   router fails the other can take the traffic.

   Keep in mind that from a packet path forwarding decision process,
   these routers are speaking other protocols as well.  There is dynamic
   information being shared between these closely coupled routers that
   lets them do the right thing.


3.  With respect to Joe's question about are there numbers for DNS use
    of IP protocols (UDP vs TCP).  Yes, there are.  RIPE published or
publishes traffic numbers. I'm not sure if the URL's I have are
    "public" or not.  Ask them.   Or do a little NetFlow work of your
    own.....

I realize that many on this list don't reply to the troll food that Dean leaves around, but I felt it important to reply as someone thats NOT in any shape fashion or form, ISC or its staff. I am somone that has done the engineering work to make a different letter work better via Anycast.
Which letter, well that doesn't matter.

Bottom line:  Depending on your technical requirements, the protocols
in use, ANYCAST works just dandy. Its another tool in the tool bag that
in the right conditions does the job in a simple and clean manner.  Just
like a surgeon needs to know what type of tool to use, network engineers need to know what "tools" to use.

Would I do TCP based anycast, nope.
Would I do UDP based anycast, YES and I'm doing it for my networks

John Brown, CTO
Chagres Technologies, Inc  (Americas)
Chagres Technologies, BV   (EMEA)
Building Global IP and VOIP networks.

Dean Anderson wrote:
On Thu, 30 Sep 2004, Joe Shen wrote:


Would you please give more about  the problem of  anycast with root
server ?


I notice that Paul Vixie already replied, and as usual, oversimplified and gave no useful information. It unclear if he is being deliberately vague or if he truly doesn't understand the implications of your questions.


To my understanding, Per-Packet Load Balancing works only in situation
all DNS servers installed behind the same router, and it CAN NOT
guarantee sequencing of TCP packets.


That is basically correct, and is possible for a customer/end user DNS
setup with only one router. A root anycast setup is different in that root
servers are located at sites that have more than one (usually many more
than one) connection (peering or transit)  with other providers, and thus
are not 'behind the same router'.  If those providers, or their customers
or peers also have multiple paths, and if one of those customers or peers
enables PPLB, then TCP packets would go to any of the anycast servers. For example, the ISC-TN-2004-1 shows a diagram with 2 routers, breaking the "everything behind one router" requirement necessary for anycast. Apparently, Vixie/ISC really doesn't understand the constraints required for anycast operation, in particular, the "behind one router" constraint.

Also, it is not merely the sequencing of packets that causes a problem
(though this causes a minor problem), but the fact that some packets are
delivered to entirely different anycast servers and so a TCP connection
can't be established under the condition of PPLB to a group of anycast
servers behind multiple routers.


The first problem of PPLB is , it could not be implemented for a server
farm which distributes across internet, and the only thing it does is
replacing traditional load balancer with router.


PPLB is incompatible with anycast. Any situation where the anycast server has multiple paths to the internet is subject to PPLB use by some other provider which could send packets over those paths, ultimately to different servers.

It is not enough for the routers at the multihomed anycast root server
farm not to do PPLB. It would be necessary to require that no one anywhere
do PPLB under the multiple router circumstance since each router will have
different cache to one of the anycast servers. And of course, the
requirement that no one anywhere can use PPLB is unreasonble.



I don't know whether there is some research in "how many packets does
one DNS request cost " and "how many TCP traffic occupies in DNS
traffic".  If most of DNS request cost more than one UDP packets,
out-of-sequence may be a problem. Also , if TCP occupies more than 10%
of traffic it will also be a problem.

The third, ECMP in current DNS server farm guarantees both per-packet
load balancing in UDP traffic and per-flow distribution in TCP traffic. Considering distributing DNS server across multiple AS, I think the
advange is obvious than PPLB.



Joe Shen


ps.  where can I find detailed information on Root server GTLD server
configuration  ( hardware , software, and network infrastructure)?
       I just know they use anycast but how they choose system
platform?


-----Original Message-----
From: owner-dnsop(_at_)lists(_dot_)uoregon(_dot_)edu
[mailto:owner-dnsop(_at_)lists(_dot_)uoregon(_dot_)edu] On Behalf Of Dean 
Anderson
Sent: Thursday, September 30, 2004 5:41 AM
To: ietf(_at_)ietf(_dot_)org
Cc: dnsop(_at_)lists(_dot_)uoregon(_dot_)edu
Subject: [dnsop] Re: Root Anycast (fwd)


Some time back we were talking about anycast being a bad thing on DNS
Root servers. It was suggested by that conversations typically take only
one path as a result of CEF-like caching.  I noted that providers were
working on per packet load balancing. Well, here it is, in the "major
vendor":

Per-Packet Load Balancing
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft
/120limit/120s/120s21/pplb.htm

So, it seems that we need to review whether the use of anycast on the
root nameservers is a good idea. I suggest that we ignore for the
momeent anyway the question of whether the deployment of anycast was
done with adequate technical analysis, discussion, and approval, and
just consider whether we should continue doing it.  However, the Root
server operation and oversight issues are very important should also be
discussed, too, but probably by different forums.

                --Dean

---------- Forwarded message ----------
Date: Tue, 18 May 2004 19:03:52 -0400 (EDT)
From: Dean Anderson <dean(_at_)av8(_dot_)com>
To: Paul Vixie <vixie(_at_)vix(_dot_)com>
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Root Anycast

On 18 May 2004, Paul Vixie wrote:


Careful design by whom? Organic compared to what? I assure you that f-root has grown by careful design. It's only organic in that we go where we're invited rather than having a gigantic budget that could be

used as a leash.

Do you mean "Careful Design" like the non-standard changes in Bind 9
AXFR and IXFR?  I don't think we can take too much of that sort of thing
in the operation of the root servers before we have serious problems.

Unilateral action is not a good thing. There is no point in having an
IETF (Remember the "Internet __Engineering__ Task Force" in IETF) if you
just implement whatever you think OK at the moment (AXFR mods, IXFR
mods, Anycast, and probably more that we just don't yet know about)

                --Dean


--
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000





.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html






_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf