[e2e] TCP improved closing strategies?

rick jones perfgeek at mac.com
Thu Aug 13 08:53:58 PDT 2009


On Aug 13, 2009, at 5:58 AM, William Allen Simpson wrote:
> AFAIK, the last survey (6-7 years ago) was 100 million queries per  
> day, so
> that's roughly 694,444 during each 2MSL period.  Of course, that's  
> average,
> not peak (likely much more)....
>
> http://dns.measurement-factory.com/writings/wessels-pam2003-paper.pdf
>
> We're talking about Linux, Solaris, HP-UX, AIX, maybe some others.  
> Do all
> these servers have the capability to handle that many TCP connections,
> rather than UDP connections?
>
> Do *any* of them?

Modulo the variations in how persistent the connections were relative  
to the transaction rate, and the differences in the metrics, you can  
probably look at the archives of SPECweb96 (HTTP 1.0) SPECweb99 (1.1),  
SPECweb99_SSL (new SSL session for each new TCP connection, IIRC, but  
it has been a while) or even SPECweb2005/SPECweb2009 if you can decide  
which among "Banking," "Ecommerce," and "Support" workload is closest,  
to get an idea of how many TCP connections servers can handle.  During  
the heyday of web server benchmarking, there was a lot of work done in  
minimizing the overhead of TIME_WAIT tracking etc.

>> That said, the problem is fun.
>> 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???
> 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.)

Isn't a new TCP option by definition depending on the client's OS to  
be smart?

rick jones
Wisdom teeth are impacted, people are affected by the effects of events



More information about the end2end-interest mailing list