<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<font face="Helvetica, Arial, sans-serif">The function of the TCP close
protocol has two parts:<br>
<br>
1) a "semantic" property that indicates to the *applications* on each
end that there will be no more data and that all data sent has been
delivered. (this has the usual problem that "exactly once" semantics
cannot be achieved, and TCP provides "at most once" data delivery
semantics on the data octet just prior to the close. Of course, *most*
apps follow the end-to-end principle and use the TCP close only as an
"optimization" because they use their data to provide all the necessary
semantics for their needs.<br>
<br>
2) a "housekeeping" property related to keeping the TCP-layer-state
minimal. This is what seems to be of concern here.<br>
<br>
Avoiding (2) for many parts of TCP is the reason behind "Trickles"
(q.v.) a version of TCP that moves state to the client side.<br>
If we had a "trickles" version of TCP (which could be done on top of
UDP) we could get all the functions of TCP with regard to (2) without
server side overloading, other than that necessary for the app itself.<br>
<br>
Of course, "trickles" is also faithful to all of TCP's end-to-end
congestion management and flow control, etc. None of which is needed
for the DNS application - in fact, that stuff (slowstart, QBIC, ...) is
really ridiculous to think about in the DNS requirements space (as it
is also in the HTML page serving space, given RTT and bitrates we
observe today, but I can't stop the a academic hotrodders from their
addiction to tuning terabyte FTPs from unloaded servers for 5 %
improvements over 10% lossy links).<br>
<br>
You all should know that a very practical fix to both close-wait and
syn-wait problems is to recognize that 500 *milli*seconds is a much
better choice for lost-packet timeouts these days - 250 would be pretty
good. Instead, we have a default designed so that a human drinking
coffee with one hand can drive a manual connection setup one packet at
a time using DDT on an ASR33 TTY while having a chat with a
co-worker. And the result is that we have DDOS attacks...<br>
<br>
I understand the legacy problems, but really. If we still designed
modern HDTV signals so that a 1950 Dumont console TV could show a
Blu-Ray movie, we'd have not advanced far.<br>
<br>
</font><br>
On 08/17/2009 10:16 AM, Joe Touch wrote:
<blockquote cite="mid:4A896637.4010907@isi.edu" type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William Allen Simpson wrote:
...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">As I recall Andy Tanenbaum used to point out that TP4 had an abrupt close
and it worked. It does require somewhat more application coordination
but
perhaps we can fake that by, say, retransmitting the last segment and
the FIN
a few times to seek to ensure that all data is received by the client???
</pre>
</blockquote>
<pre wrap="">Cannot depend on the DNS client's OS to be that smart. Has to be a server
only solution. Or based on a new TCP option, that tells us both ends are
smart. (I've an option in mind.)
</pre>
</blockquote>
<pre wrap="">
There are two different problems here:
1) server maintaining state clogging the server
2) server TIME-WAIT slowing connections to a single address
Both go away if the client closes the connection. If you are going to
modify both ends, then that's a much simpler place to start than a TCP
option (which will need to be negotiated during the SYN, and might be
removed/dropped by firewalls or NATs, etc.).
FWIW, persistent connections helps only #2. If it's the number of
different clients connecting a server that is locking up too much server
memory, then persistent connections will make the problem worse, not better.
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a>
iEYEARECAAYFAkqJZjcACgkQE5f5cImnZruodwCeI3Lgpd8FNgsVt/g/FxPG29He
NAAAoOXx0XeCkuadd26u87RBfnNSro3k
=ZI0g
-----END PGP SIGNATURE-----
</pre>
</blockquote>
</body>
</html>