Re: TCP information
Dan Nelson wrote: These types of statistics aren't kept. They usually do not make it into commercial product distributions for performance reasons, and because every byte added to a tcpcb structure is one byte less that can be used for something else. In practice, adding 134 bytes of statistics to a tcpcb would double its size and halve the number of simultaneous connections you would be able to support with the same amount of RAM in a given machine (as one example), if all of that memory had to come out of the same space, all other things being equal. tcpcb is currently 236 bytes though, and I don't imagine adding another 8 bytes for an unsigned long dropped packets counter is going to kill him. 236 is too large. We do stupid things like not compressing the state. For example, there is state that is unique to a listen socket and state that is unique to a connecting socket: this state should be in a union, so that tcpcb's are smaller. The kqueue bloat, particularly that for accept filters is another issue. So is the bloated credential and other information, most of which belongs in application-specific extension data chains that are *only* used when the aplication is active vs. the TCP connection (e.g. when IPSec is active, when kqueues have been registered, etc.). In 4.x, the structure size was 134 bytes (maybe 136; depends on which 4.x, I guess). The exra 100 bytes are cruft. Removing the cruft and compressing the state with a union would get you just under 128 bytes, so the current structure is almost 100% additional bloat for features that are rarely used, or are used, but are generally only in effect on a small number of the open sockets you are dealing with; very very annoying. Deepak: if you really want stats, try adding a struct tcpstat to tcpcb and hack all the netinet/tcp* code to update those whenever the global tcpstat gets updated. You'll get all the info that netstat -s prints, for each socket. *That* will definitely double the size of struct tcpcb :) The statistics gathering really should be macrotized, and a macro declaration added for this. You could then make it a compile-time option as to whether or not you gather the stats (default to off!). Assuming some FreeBSD committer is willing to stick the macros in the headers and the instrumentation points. If you did the extension structure chaining trick, noted above, you could even make it runtime adjustable; however, you would need to (1) add a timestamp to the structure to indicate the start time for statistics gathering and (2) walk the list of open sockets to add an extension for each of the already open sockets in the system. You could even have a seperate set of commands (I would suggest a psuedo device driver for doing it) to enable/start/stop/disable, so you can leave dormant extension structure lying around to control sample intervals separated by non-sample intervals of indeterminate length. Either way, though, I think you would want it to be off by default, just like you want the IPSEC to be off by default, given that it soaks up a huge default object per socket just by bing compiled in, even if the socket never actually uses the feature. 8-(. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP information
Deepak Jain wrote: If the tcpcb struct were expanded/changed and the various increments were added in the appropriate packet pushing code, this would work right? Is there something non-obvious that one would need to worry about to undertake such a project? Your overhead would be slightly higher when doing statistics, because you would need to store more information for each of the statistics you wanted to gather. The main reasonable objections to doing this by default would be (1) added overhead and (2) increased per-connection costs. The first of these is an issue for everybody. The second of these would be an issue for connections which remain idle for significant fractions of time. I'd call 20% or more of the time idle significant for this purpose, so you could include FTP control channels, HTTP persistent connections, IMAP4 connections, database entry screens, and pretty much anything else that was client/server, had a slow human on one end of the client, and a persistent connection to the server on the other. See my other posting on how to do this at a slightly higher cost, but only when it's enabled, via a pointer indirection, or at equal cost without one, as a compile-time option. I think that approach would be better for your purposes, particularly if you wanted to offload the code maintenance, rather than reintegrating a lot of patches for each release you wanted to run on. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP information
Deepak Jain wrote: Is there a utility/hack/patch that would allow a diligent sysadmin to obtain which specific TCP connections are generating retransmits and receiving packet drops? netstat will show me drops on an interface, but not on a specific source/dest pair? I am guessing something like a netstat -n, but instead of showing send/rec queues it shows retransmit or packet drops? Would there be much interest in this feature if we were to build it ourselves? These types of statistics aren't kept. Generally, they are used only by network researchers, who hack their stacks to get them. They usually do not make it into commercial product distributions for performance reasons, and because every byte added to a tcpcb structure is one byte less that can be used for something else. In practice, adding 134 bytes of statistics to a tcpcb would double its size and halve the number of simultaneous connections you would be able to support with the same amount of RAM in a given machine (as one example), if all of that memory had to come out of the same space, all other things being equal. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP information
In the last episode (Sep 18), Terry Lambert said: Deepak Jain wrote: Is there a utility/hack/patch that would allow a diligent sysadmin to obtain which specific TCP connections are generating retransmits and receiving packet drops? netstat will show me drops on an interface, but not on a specific source/dest pair? These types of statistics aren't kept. They usually do not make it into commercial product distributions for performance reasons, and because every byte added to a tcpcb structure is one byte less that can be used for something else. In practice, adding 134 bytes of statistics to a tcpcb would double its size and halve the number of simultaneous connections you would be able to support with the same amount of RAM in a given machine (as one example), if all of that memory had to come out of the same space, all other things being equal. tcpcb is currently 236 bytes though, and I don't imagine adding another 8 bytes for an unsigned long dropped packets counter is going to kill him. Deepak: if you really want stats, try adding a struct tcpstat to tcpcb and hack all the netinet/tcp* code to update those whenever the global tcpstat gets updated. You'll get all the info that netstat -s prints, for each socket. *That* will definitely double the size of struct tcpcb :) -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: TCP information
If you've got a small enough amount of traffic, you could use tcpdump to snarf the headers and then use your favourite scripting languge to look for repeated sequence numbers (retransmits) and repeated acks (lost packets); but I suspect this would be too slow for most purposes. Yeah, we thought about using a sniffer in front of a box to accomplish the same task to overcome the performance issue, but a more direct way would really be suitable to our application. Thanks! Deepak Jain AiNET ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP information
On Wed, Sep 17, 2003 at 08:34:54PM -0400, Deepak Jain wrote: Is there a utility/hack/patch that would allow a diligent sysadmin to obtain which specific TCP connections are generating retransmits and receiving packet drops? netstat will show me drops on an interface, but not on a specific source/dest pair? Such a thing would need to be written, or adapted from an existing tcp tool. ports/net/trafd would probably be a good place to start. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP information
In the last episode (Sep 18), Terry Lambert said: **snip** tcpcb is currently 236 bytes though, and I don't imagine adding another 8 bytes for an unsigned long dropped packets counter is going to kill him. Deepak: if you really want stats, try adding a struct tcpstat to tcpcb and hack all the netinet/tcp* code to update those whenever the global tcpstat gets updated. We spent a lot of effort doing this for our 3.5-based NAT/firewall products, putting the SEQ/ACK numbers and related re-transission counts in the struct we used for transient connection objects, and logged them when the connection closed. With 10K simultaneous connections active, it added less than 640K of malloc'd memory, so it's not a big hit. We didn't find the statistics we gathered to be meaningful, BTW. Transient errors (congestion and routing loops) were infrequent, and most of what looked like errors turned out to be generated by the stack at the other end (gratuitous back-to-back ACKs and packet retransmission before any possible timeout could occur). For us, a waste of time. If you have more interesting results, please let me know. I figured it would be a great tool. -Les -- Les Biffle CISSP Information Systems Security Consultant (480) 585-4099 [EMAIL PROTECTED] http://www.les.biffle.org/ Network Safety, PO Box 14461, Scottsdale, AZ 85267 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: TCP information
These types of statistics aren't kept. Generally, they are used only by network researchers, who hack their stacks to get them. They usually do not make it into commercial product distributions for performance reasons, and because every byte added to a tcpcb structure is one byte less that can be used for something else. In practice, adding 134 bytes of statistics to a tcpcb would double its size and halve the number of simultaneous connections you would be able to support with the same amount of RAM in a given machine (as one example), if all of that memory had to come out of the same space, all other things being equal. If the tcpcb struct were expanded/changed and the various increments were added in the appropriate packet pushing code, this would work right? Is there something non-obvious that one would need to worry about to undertake such a project? Thanks, Deepak Jain AiNET ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP information
At 20:34 17/09/2003 -0400, Deepak Jain wrote: Is there a utility/hack/patch that would allow a diligent sysadmin to obtain which specific TCP connections are generating retransmits and receiving packet drops? netstat will show me drops on an interface, but not on a specific source/dest pair? If you've got a small enough amount of traffic, you could use tcpdump to snarf the headers and then use your favourite scripting languge to look for repeated sequence numbers (retransmits) and repeated acks (lost packets); but I suspect this would be too slow for most purposes. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
