[e2e] TCP improved closing strategies?

[David P. Reed]

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.

On 08/17/2009 10:03 PM, rick jones wrote:
>> 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
>
> Would DNS query processing ever even see slowstart artifacts?  99 
> times out of 10 the initial cwnd is 4380 bytes or somesuch right?
>
>> (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).
>
> If the FSI guys had their say, latency would be king.
>
>> 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.
>
> I thought many/most stacks used 500 milliseconds for their TCP RTO 
> lower bound already?
>
>> And the result is that we have DDOS attacks...
>
> Well... are the constants really the heart of that issue?
>
>> 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.
>
> I must disagree with the presumption that TV has progressed far since 
> the 1950's.  At least in so far as content is concerned :)
>
> rick jones
> http://homepage.mac.com/perfgeek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090818/2f2c9b9c/attachment.html