Selective ACKnowledgement options (SACK) RFC 2018
Advanced TCP congestion algorithms
For some basic algorithms and background, see RFC 2581.
An algorithm to detect unecessary loss recovery, which is costly, using TCP Timestamps options. Good in wireless LAN environments where this might happen more often.
Limited Transmit RFC 3042
Improves TCP's loss recovery. This helps busy webservers.
Early Retransmit IETF draft
Speeds up short transfers, like many web requests.
D-SACK (Duplicate-SACK) RFC 2883
An extension to the SACK option.
Appropriate Byte Counting RFC 3465
An algorithm for increasing TCP's congestion window, which improves throughput and protects against optimistic ACK attacks.
06:44 <dt_> does anyone have any idea what the maximum number of simultanous tcp network connections df can have is? 06:45 <hsu> depends on how much memory you have in the machine 06:46 <hsu> as a rough measure, it's mem/1000 06:46 <hsu> for inactive connections 06:46 <dt_> mem in bytes? 06:46 <hsu> for active connections, it's more like mem/32K 06:46 <hsu> yes 06:47 <dt_> so more memory is allocated for accepted connections? 06:47 <hsu> most of the memory for active connections is sitting in the sockbuf 06:47 <hsu> that dwarves everything else 06:48 <hsu> however, some large network servers have millions of inactive connections 06:48 <dt_> thanks hsu 06:48 <hsu> big difference in divisors between 1K and 32K 06:49 <hsu> note: this is kmem and oversimplifies by assuming you're using all of kmem for network connections and you don't need it for anything else, like filesystem buffers 06:49 <dt_> still much better than windows, nt 4.0 is limited to 12,800 and w2k to 25,600 active connections 06:49 <hsu> but's it's accurate to the rough order of magnitude 06:49 <dt_> despite memory 06:49 <hsu> oh, you can have much more than that w/ dfly 06:49 <hsu> you do have to up some sysctl limits though 06:50 <hsu> like kern.ipc.maxsockets 06:50 <hsu> and kern.ipc.nmbufs 06:51 <hsu> also, if you decrease kern.ipc.maxsockbuf to, say, 8K, then you can have roughly kmem/8K number of active connections 06:52 <hsu> basically, you're limited by the amount of memory that each connection takes, not by cpu resources 06:52 <hsu> for inactive connections, the tcpcb state is roughly 1K 06:52 <dt_> can thos sysctrl be adjusted at any time? will new connections change with them? 06:52 <hsu> for active connections, the amount of data sitting in sockbufs dominates, so it depends on your setting of kern.ipc.maxsockbuf 06:52 <hsu> yes 06:52 <dt_> awsome 06:53 <hsu> it helps if you're on a 64-bit processor w/ > 4GB of memory 06:53 <hsu> before, that 4GB limit was pretty hard to overcome 06:54 <hsu> now, just stuff up your board and you can increase capacity 06:54 <hsu> oh, you might have to increase kern.maxfilesperproc too 06:54 <hsu> if your network server is all in one process 06:54 <hsu> service 06:55 <hsu> finally, if you use sendfile, then you don't have to worry about sockbuf memory, since you get to share file buffers among connections 06:56 <hsu> applicable for the case where you have a web server sending out static file content
Note that DragonFlyBSD hasn't been ported to any 64-bit architectures yet.