[e2e] TCP improved closing strategies?
perfgeek at mac.com
Mon Aug 17 19:03:25 PDT 2009
> 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 :)
More information about the end2end-interest