15 * Selective ACKnowledgement options (SACK) [RFC 2018](http://www.ietf.org/rfc/rfc2018.txt)
\r
17 * Advanced TCP congestion algorithms
\r
19 For some basic algorithms and background, see [RFC 2581](http://www.ietf.org/rfc/rfc2581.txt).
\r
22 * Eifel Detection [RFC 3522](http://www.ietf.org/rfc/rfc3522.txt), [RFC 4015](http://www.ietf.org/rfc/rfc4015.txt)
\r
24 An algorithm to detect unecessary loss recovery, which is costly, using TCP Timestamps options.
\r
25 Good in wireless LAN environments where this might happen more often.
\r
28 * Limited Transmit [RFC 3042](http://www.ietf.org/rfc/rfc3042.txt)
\r
30 Improves TCP's loss recovery. This helps busy webservers.
\r
33 * Early Retransmit [IETF draft](ftp://ftp.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-04.txt)
\r
35 Speeds up short transfers, like many web requests.
\r
38 * D-SACK (Duplicate-SACK) [RFC 2883](http://www.ietf.org/rfc/rfc2883.txt)
\r
40 An extension to the SACK option.
\r
43 * Appropriate Byte Counting [RFC 3465](http://www.ietf.org/rfc/rfc3465.txt)
\r
45 An algorithm for increasing TCP's congestion window,
\r
46 which improves throughput and protects against optimistic ACK attacks.
\r
50 06:44 <dt_> does anyone have any idea what the maximum number of simultanous tcp network connections df can have is?
\r
51 06:45 <hsu> depends on how much memory you have in the machine
\r
52 06:46 <hsu> as a rough measure, it's mem/1000
\r
53 06:46 <hsu> for inactive connections
\r
54 06:46 <dt_> mem in bytes?
\r
55 06:46 <hsu> for active connections, it's more like mem/32K
\r
57 06:47 <dt_> so more memory is allocated for accepted connections?
\r
58 06:47 <hsu> most of the memory for active connections is sitting in the sockbuf
\r
59 06:47 <hsu> that dwarves everything else
\r
60 06:48 <hsu> however, some large network servers have millions of inactive connections
\r
61 06:48 <dt_> thanks hsu
\r
62 06:48 <hsu> big difference in divisors between 1K and 32K
\r
63 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
\r
64 06:49 <dt_> still much better than windows, nt 4.0 is limited to 12,800 and w2k to 25,600 active connections
\r
65 06:49 <hsu> but's it's accurate to the rough order of magnitude
\r
66 06:49 <dt_> despite memory
\r
67 06:49 <hsu> oh, you can have much more than that w/ dfly
\r
68 06:49 <hsu> you do have to up some sysctl limits though
\r
69 06:50 <hsu> like kern.ipc.maxsockets
\r
70 06:50 <hsu> and kern.ipc.nmbufs
\r
71 06:51 <hsu> also, if you decrease kern.ipc.maxsockbuf to, say, 8K, then you can have roughly kmem/8K number of active connections
\r
72 06:52 <hsu> basically, you're limited by the amount of memory that each connection takes, not by cpu resources
\r
73 06:52 <hsu> for inactive connections, the tcpcb state is roughly 1K
\r
74 06:52 <dt_> can thos sysctrl be adjusted at any time? will new connections change with them?
\r
75 06:52 <hsu> for active connections, the amount of data sitting in sockbufs dominates, so it depends on your setting of kern.ipc.maxsockbuf
\r
78 06:53 <hsu> it helps if you're on a 64-bit processor w/ > 4GB of memory
\r
79 06:53 <hsu> before, that 4GB limit was pretty hard to overcome
\r
80 06:54 <hsu> now, just stuff up your board and you can increase capacity
\r
81 06:54 <hsu> oh, you might have to increase kern.maxfilesperproc too
\r
82 06:54 <hsu> if your network server is all in one process
\r
84 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
\r
85 06:56 <hsu> applicable for the case where you have a web server sending out static file content
\r
87 ***Note that DragonFlyBSD hasn't been ported to any 64-bit architectures yet.***
\r