Put in remaining pages and wiki contents.
[ikiwiki.git] / docs / developer / Status-NetworkStack.mdwn
1 ### TODO \r
2 \r
3
4 * Parallel TCP\r
5
6 * Parallel routing\r
7
8 * Parallel IPv6\r
9 \r
10 ### DONE \r
11 \r
12
13 * Parallel IPv4\r
14
15 * Selective ACKnowledgement options (SACK) [RFC 2018](http://www.ietf.org/rfc/rfc2018.txt)\r
16
17 * Advanced TCP congestion algorithms\r
18 \r
19       For some basic algorithms and background, see [RFC 2581](http://www.ietf.org/rfc/rfc2581.txt).\r
20 \r
21
22 * Eifel Detection [RFC 3522](http://www.ietf.org/rfc/rfc3522.txt), [RFC 4015](http://www.ietf.org/rfc/rfc4015.txt)\r
23 \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
26 \r
27
28 * Limited Transmit [RFC 3042](http://www.ietf.org/rfc/rfc3042.txt)\r
29 \r
30         Improves TCP's loss recovery. This helps busy webservers.\r
31 \r
32
33 * Early Retransmit [IETF draft](ftp://ftp.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-04.txt)\r
34 \r
35         Speeds up short transfers, like many web requests.\r
36 \r
37
38 * D-SACK (Duplicate-SACK) [RFC 2883](http://www.ietf.org/rfc/rfc2883.txt)\r
39 \r
40         An extension to the SACK option.\r
41 \r
42
43 * Appropriate Byte Counting [RFC 3465](http://www.ietf.org/rfc/rfc3465.txt)\r
44 \r
45         An algorithm for increasing TCP's congestion window,\r
46         which improves throughput and protects against optimistic ACK attacks.\r
47 \r
48 ### Comments \r
49     \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
56     06:46 <hsu> yes\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
76     06:52 <hsu> yes\r
77     06:52 <dt_> awsome\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
83     06:54 <hsu> service\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
86 \r
87 ***Note that DragonFlyBSD hasn't been ported to any 64-bit architectures yet.***\r