tcp limitations

[Guy Pazi]

Hi again, Jim

> -----Original Message-----
> From: Jim Reid [mailto:jim at rfc1035.com]
> Sent: Tuesday, 12 June, 2001 4:01 PM
> To: Guy Pazi
> Cc: Brad Knowles; bind-users at isc.org
> Subject: Re: tcp limitations 
> 
> 
> >>>>> "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 behavior 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.
I don't remember saying the number of queries to be requested by resolvers
will change, I was asking what number of tcp connections will the SERVER
support. So how many packets will be sent by Fed-Ex before Fed-Ex will have
no one who will accept them? or, let's be metaphoric, when will the server
start to drop (rst?) new requests for tcp connection?

> 
> 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.
> 
Again, Jim, I never suggested that tcp will reduce dns traffic, and I quite
agree with all you write (well, the technical staff, anyway), but tcp has
its advantages in my eyes, some of which you might disagree, and some you
are not aware of. So This is what I'm going to use.
Now, assuming this is the situation, lets go back to what you wrote: 
"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), ".
So, When will this 'eventually' happen?

One more thing:
Standards are great things. They have lots of advantages, they enable
everyone to use the same thing correctly. But, by trying to be standards,
they are a compromise between everyone's need.
When trying to do an internal task, trying to use the standard is good for
certain reasons, but a propriety solution might sometime fit better.
Sticking to standards by all cost is a bit narrow minding, as I see it.

Guy 



-- Binary/unsupported file stripped by Listar --
-- Type: application/ms-tnef
-- File: winmail.dat