<!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">Minor misunderstanding... I
was referring to all of the advanced logic and state needed to manage
TCP flow control when I mentioned "slow start" - and NOT any
"artifacts". The only thing needed for a DNS message and response is
dealing with assembling an application message from a small number of
packets. Both the request and the response (in DNS at the application
level) make no meaningful change to the state variables at either end,
so they are commutative and idempotent operations with respect to all
other DNS requests and all other DNS responses. That makes almost all
of the "semantic functionality" of TCP irrelevant, and means that
"connection state" is flushable.</font><br>
<br>
On 08/17/2009 10:03 PM, rick jones wrote:
<blockquote cite="mid:F50F8F58-8EB0-42A3-A519-CDC7D0F72499@mac.com"
type="cite">
<blockquote type="cite">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
<br>
</blockquote>
<br>
Would DNS query processing ever even see slowstart artifacts? 99 times
out of 10 the initial cwnd is 4380 bytes or somesuch right?
<br>
<br>
<blockquote type="cite">(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>
</blockquote>
<br>
If the FSI guys had their say, latency would be king.
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
I thought many/most stacks used 500 milliseconds for their TCP RTO
lower bound already?
<br>
<br>
<blockquote type="cite">And the result is that we have DDOS
attacks...
<br>
</blockquote>
<br>
Well... are the constants really the heart of that issue?
<br>
<br>
<blockquote type="cite">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>
</blockquote>
<br>
I must disagree with the presumption that TV has progressed far since
the 1950's. At least in so far as content is concerned :)
<br>
<br>
rick jones
<br>
<a class="moz-txt-link-freetext" href="http://homepage.mac.com/perfgeek">http://homepage.mac.com/perfgeek</a>
<br>
<br>
<br>
</blockquote>
</body>
</html>