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