tcp limitations

[Jim Reid]

>>>>> "Guy" == Guy Pazi <guy at wanwall.com> writes:

    Guy> But, lets say for a minute, all queries were tcp. What ~
    Guy> number of queries/sec will a root name server support drop
    Guy> down to, from the 2-5k udp queries/sec?

What makes you think the number of queries will change because the
underlying transport protocol used to shift them from one place to
another changes? The query only registers at the server once the
transport protocol has delivered it there. The behaviour of the
clients that cause the queries to be made isn't going to change
because the queries go by TCP instead of UDP. (Or Fed-ex.) They'll
still make the same number and type of queries. A TCP connection isn't
going to magically reduce a resolver's query traffic pattern or make
the upper-layer applications smarter. I suppose TCP's RTT and window
checking might make things better in a lossy or badly congested
network but probably not by much. UDP resolvers generally back off in
these circumstances already.

If anything using TCP will probably cause *more* queries on busy
servers because of the overheads of maintaining and searching an
ever-lengthening list of protocol control blocks (PCBs) for the active
TCP connections on the server. This list has to be searched for every
new inbound connection request and every inbound TCP segment. [That
overhead is one reason why DNS normally uses UDP.] Eventually the OS
will run out of PCB buffers and drop the new TCP connection request
(or take too long to search the list and drop the connection), which
probably causes the client to retry the query if it doesn't give up.