Subject: [Ecrit] faux scalability

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 16:25:09 -0400

This entire effort got started back when Brian proposed a solution  
using DNS.  He picked DNS because it is very well known that DNS  
scales.  Got into any reputable outfit dealing with scale of any  
magnitude and you'll notice that they will have many web farms,  
clustered 4 or 8  ways but perhaps only 2 DNS servers (and they'll  
readily admit that the second is not for load but for fail-over).  Of  
course, there are exceptions, but generally this is true.

DNS scales primarily for two reasons: it makes heavy use of caching  
and it consumes as few resources server-side as possible.  That  
second aspect is primarily due to the fact that DNS is almost always  
done over UDP.  Only the special exceptions default to TCP, such as  
zone transfers... which is typically an administrative function.   
Very apropos for this conversation.

By definition, a TCP connection is at least 3 times slower to setup  
than a UDP datagram because of the TCP handshake.  This is not to  
argue against TCP itself, as TCP has its advanges, but offered for  
illustrative purposes.  TLS, which sits on top of TCP, has its own  
handshake, which I believe constitutes another 4 round trips... so at  
the very least 7 times slower when not including crypto overhead than  
if we just sent the message over UDP.  Of course, crypto overhead is  
computationally expensive, so it isn't a null operation.  And of  
course, I'd be remiss to point out that we haven't even sent the  
query to the server at this point.  Finally, any HTTP authentication  
on top of that is one more roundtrip.

The suggestion to retry without TSL when TLS fails brings this up to  
11 times more packets and 11 times more latency than the original,  
scalable proposal.  I think it is easy to see how this will not scale  
any where near as efficiently as DNS.

Now consider what a LoST resolver must do.  It accepts connections  
from LoST seekers on one end and establishes connections with LoST  
authoritative servers on the other end.  A server only has a finite  
number of TCP connections it can handle, and for a LoST resolver with  
a standard tiered architecture, some of those are used up with the  
database connection pool, management ports, etc...  When the server  
has reached the limit of the number of connections it can accept, in  
coming requests have to wait for previous requests to finish.  The  
longer the resolver is held up retrying connections while hunting  
down answers, the longer requests wait.

Consider a LoST seeker in Austria resolving a location for a UA in  
New York.  11 packets to setup the connection to the Austrian LoST  
forrest guide, 11 packets when redirect to the US LoST forrest guide,  
11 packets when redirected to the New York state forrest guide, and  
11 packets to connect to the New York authoritative server.  44 more  
packets needed than the original idea.

This is not a solution with that is considerate of scalability.

-andy

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

it>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

This entire effort got started back when Brian proposed a solution  
using DNS.  He picked DNS because it is very well known that DNS  
scales.  Got into any reputable outfit dealing with scale of any  
magnitude and you'll notice that they will have many web farms,  
clustered 4 or 8  ways but perhaps only 2 DNS servers (and they'll  
readily admit that the second is not for load but for fail-over).  Of  
course, there are exceptions, but generally this is true.

DNS scales primarily for two reasons: it makes heavy use of caching  
and it consumes as few resources server-side as possible.  That  
second aspect is primarily due to the fact that DNS is almost always  
done over UDP.  Only the special exceptions default to TCP, such as  
zone transfers... which is typically an administrative function.   
Very apropos for this conversation.

By definition, a TCP connection is at least 3 times slower to setup  
than a UDP datagram because of the TCP handshake.  This is not to  
argue against TCP itself, as TCP has its advanges, but offered for  
illustrative purposes.  TLS, which sits on top of TCP, has its own  
handshake, which I believe constitutes another 4 round trips... so at  
the very least 7 times slower when not including crypto overhead than  
if we just sent the message over UDP.  Of course, crypto overhead is  
computationally expensive, so it isn't a null operation.  And of  
course, I'd be remiss to point out that we haven't even sent the  
query to the server at this point.  Finally, any HTTP authentication  
on top of that is one more roundtrip.

The suggestion to retry without TSL when TLS fails brings this up to  
11 times more packets and 11 times more latency than the original,  
scalable proposal.  I think it is easy to see how this will not scale  
any where near as efficiently as DNS.

Now consider what a LoST resolver must do.  It accepts connections  
from LoST seekers on one end and establishes connections with LoST  
authoritative servers on the other end.  A server only has a finite  
number of TCP connections it can handle, and for a LoST resolver with  
a standard tiered architecture, some of those are used up with the  
database connection pool, management ports, etc...  When the server  
has reached the limit of the number of connections it can accept, in  
coming requests have to wait for previous requests to finish.  The  
longer the resolver is held up retrying connections while hunting  
down answers, the longer requests wait.

Consider a LoST seeker in Austria resolving a location for a UA in  
New York.  11 packets to setup the connection to the Austrian LoST  
forrest guide, 11 packets when redirect to the US LoST forrest guide,  
11 packets when redirected to the New York state forrest guide, and  
11 packets to connect to the New York authoritative server.  44 more  
packets needed than the original idea.

This is not a solution with that is considerate of scalability.

-andy

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit