[e2e] TCP improved closing strategies?

[rick jones]

> 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