xref: /freebsd/share/man/man4/siftr.4 (revision 9a14aa017b21c292740c00ee098195cd46642730)
1.\"
2.\" Copyright (c) 2010 The FreeBSD Foundation
3.\" All rights reserved.
4.\"
5.\" Portions of this software were developed at the Centre for Advanced
6.\" Internet Architectures, Swinburne University of Technology, Melbourne,
7.\" Australia by Lawrence Stewart under sponsorship from the FreeBSD
8.\" Foundation.
9.\"
10.\" Redistribution and use in source and binary forms, with or without
11.\" modification, are permitted provided that the following conditions
12.\" are met:
13.\" 1. Redistributions of source code must retain the above copyright
14.\"    notice, this list of conditions, and the following disclaimer,
15.\"    without modification, immediately at the beginning of the file.
16.\" 2. The name of the author may not be used to endorse or promote products
17.\"    derived from this software without specific prior written permission.
18.\"
19.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
20.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
21.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
22.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
23.\" ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
24.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
25.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
26.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
27.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
28.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
29.\" SUCH DAMAGE.
30.\"
31.\" $FreeBSD$
32.\"
33.Dd November 12, 2010
34.Dt SIFTR 4
35.Os
36.Sh NAME
37.Nm SIFTR
38.Nd Statistical Information For TCP Research
39.Sh SYNOPSIS
40To load
41.Ns Nm
42as a module at run-time, run the following command as root:
43.Bd -literal -offset indent
44kldload siftr
45.Ed
46.Pp
47Alternatively, to load
48.Ns Nm
49as a module at boot time, add the following line into the
50.Xr loader.conf 5
51file:
52.Bd -literal -offset indent
53siftr_load="YES"
54.Ed
55.Sh DESCRIPTION
56.Nm
57.Ns ( Em S Ns tatistical
58.Em I Ns nformation
59.Em F Ns or
60.Em T Ns CP
61.Em R Ns esearch )
62is a kernel module that logs a range of statistics on active TCP connections to
63a log file.
64It provides the ability to make highly granular measurements of TCP connection
65state, aimed at system administrators, developers and researchers.
66.Ss Compile-time Configuration
67The default operation of
68.Nm
69is to capture IPv4 TCP/IP packets.
70.Nm
71can be configured to support IPv4 and IPv6 by uncommenting:
72.Bd -literal -offset indent
73CFLAGS+=-DSIFTR_IPV6
74.Ed
75.Pp
76in
77.Aq sys/modules/siftr/Makefile
78and recompiling.
79.Pp
80In the IPv4-only (default) mode, standard dotted decimal notation (e.g.
81"136.186.229.95") is used to format IPv4 addresses for logging.
82In IPv6 mode, standard dotted decimal notation is used to format IPv4 addresses,
83and standard colon-separated hex notation (see RFC 4291) is used to format IPv6
84addresses for logging. Note that SIFTR uses uncompressed notation to format IPv6
85addresses.
86For example, the address "fe80::20f:feff:fea2:531b" would be logged as
87"fe80:0:0:0:20f:feff:fea2:531b".
88.Ss Run-time Configuration
89.Nm
90utilises the
91.Xr sysctl 8
92interface to export its configuration variables to user-space.
93The following variables are available:
94.Bl -tag -offset indent
95.It Va net.inet.siftr.enabled
96controls whether the module performs its
97measurements or not.
98By default, the value is set to 0, which means the module
99will not be taking any measurements.
100Having the module loaded with
101.Va net.inet.siftr.enabled
102set to 0 will have no impact on the performance of the network stack, as the
103packet filtering hooks are only inserted when
104.Va net.inet.siftr.enabled
105is set to 1.
106.El
107.Bl -tag -offset indent
108.It Va net.inet.siftr.ppl
109controls how many inbound/outbound packets for a given TCP connection will cause
110a log message to be generated for the connection.
111By default, the value is set to 1, which means the module will log a message for
112every packet of every TCP connection.
113The value can be set to any integer in the range [1,2^32], and can be changed at
114any time, even while the module is enabled.
115.El
116.Bl -tag -offset indent
117.It Va net.inet.siftr.logfile
118controls the path to the file that the module writes its log messages to.
119By default, the file /var/log/siftr.log is used.
120The path can be changed at any time, even while the module is enabled.
121.El
122.Bl -tag -offset indent
123.It Va net.inet.siftr.genhashes
124controls whether a hash is generated for each TCP packet seen by
125.Nm .
126By default, the value is set to 0, which means no hashes are generated.
127The hashes are useful to correlate which TCP packet triggered the generation of
128a particular log message, but calculating them adds additional computational
129overhead into the fast path.
130.El
131.Ss Log Format
132A typical
133.Nm
134log file will contain 3 different types of log message.
135All messages are written in plain ASCII text.
136.Pp
137Note: The
138.Qq \e
139present in the example log messages in this section indicates a
140line continuation and is not part of the actual log message
141.Pp
142The first type of log message is written to the file when the module is
143enabled and starts collecting data from the running kernel. The text below
144shows an example module enable log. The fields are tab delimited key-value
145pairs which describe some basic information about the system.
146.Bd -literal -offset indent
147enable_time_secs=1238556193    enable_time_usecs=462104 \\
148siftrver=1.2.2    hz=1000    tcp_rtt_scale=32 \\
149sysname=FreeBSD    sysver=604000    ipmode=4
150.Ed
151.Pp
152Field descriptions are as follows:
153.Bl -tag -offset indent
154.It Va enable_time_secs
155time at which the module was enabled, in seconds since the UNIX epoch.
156.El
157.Bl -tag -offset indent
158.It Va enable_time_usecs
159time at which the module was enabled, in microseconds since enable_time_secs.
160.El
161.Bl -tag -offset indent
162.It Va siftrver
163version of
164.Nm .
165.El
166.Bl -tag -offset indent
167.It Va hz
168tick rate of the kernel in ticks per second.
169.El
170.Bl -tag -offset indent
171.It Va tcp_rtt_scale
172smoothed RTT estimate scaling factor
173.El
174.Bl -tag -offset indent
175.It Va sysname
176operating system name
177.El
178.Bl -tag -offset indent
179.It Va sysver
180operating system version
181.El
182.Bl -tag -offset indent
183.It Va ipmode
184IP mode as defined at compile time.
185An ipmode of "4" means IPv6 is not supported and IP addresses are logged in
186regular dotted quad format.
187An ipmode of "6" means IPv6 is supported, and IP addresses are logged in dotted
188quad or hex format, as described in the
189.Qq Compile-time Configuration
190subsection.
191.El
192.Pp
193The second type of log message is written to the file when a data log message
194is generated.
195The text below shows an example data log triggered by an IPv4
196TCP/IP packet.
197The data is CSV formatted.
198.Bd -literal -offset indent
199o,0xbec491a5,1238556193.463551,172.16.7.28,22,172.16.2.5,55931, \\
2001073725440,172312,6144,66560,66608,8,1,4,1448,936,1,996,255, \\
20133304,208,66608,0,208,0
202.Ed
203.Pp
204Field descriptions are as follows:
205.Bl -tag -offset indent
206.It Va 1
207Direction of packet that triggered the log message.
208Either
209.Qq i
210for in, or
211.Qq o
212for out.
213.El
214.Bl -tag -offset indent
215.It Va 2
216Hash of the packet that triggered the log message.
217.El
218.Bl -tag -offset indent
219.It Va 3
220Time at which the packet that triggered the log message was processed by
221the
222.Xr pfil 9
223hook function, in seconds and microseconds since the UNIX epoch.
224.El
225.Bl -tag -offset indent
226.It Va 4
227The IPv4 or IPv6 address of the local host, in dotted quad (IPv4 packet)
228or colon-separated hex (IPv6 packet) notation.
229.El
230.Bl -tag -offset indent
231.It Va 5
232The TCP port that the local host is communicating via.
233.El
234.Bl -tag -offset indent
235.It Va 6
236The IPv4 or IPv6 address of the foreign host, in dotted quad (IPv4 packet)
237or colon-separated hex (IPv6 packet) notation.
238.El
239.Bl -tag -offset indent
240.It Va 7
241The TCP port that the foreign host is communicating via.
242.El
243.Bl -tag -offset indent
244.It Va 8
245The slow start threshold for the flow, in bytes.
246.El
247.Bl -tag -offset indent
248.It Va 9
249The current congestion window for the flow, in bytes.
250.El
251.Bl -tag -offset indent
252.It Va 10
253The current bandwidth-controlled window for the flow, in bytes.
254.El
255.Bl -tag -offset indent
256.It Va 11
257The current sending window for the flow, in bytes.
258The post scaled value is reported, except during the initial handshake (first
259few packets), during which time the unscaled value is reported.
260.El
261.Bl -tag -offset indent
262.It Va 12
263The current receive window for the flow, in bytes.
264The post scaled value is always reported.
265.El
266.Bl -tag -offset indent
267.It Va 13
268The current window scaling factor for the sending window.
269.El
270.Bl -tag -offset indent
271.It Va 14
272The current window scaling factor for the receiving window.
273.El
274.Bl -tag -offset indent
275.It Va 15
276The current state of the TCP finite state machine, as defined
277in
278.Aq Pa netinet/tcp_fsm.h .
279.El
280.Bl -tag -offset indent
281.It Va 16
282The maximum segment size for the flow, in bytes.
283.El
284.Bl -tag -offset indent
285.It Va 17
286The current smoothed RTT estimate for the flow, in units of TCP_RTT_SCALE * HZ,
287where TCP_RTT_SCALE is a define found in tcp_var.h, and HZ is the kernel's tick
288timer.
289Divide by TCP_RTT_SCALE * HZ to get the RTT in secs. TCP_RTT_SCALE and HZ are
290reported in the enable log message.
291.El
292.Bl -tag -offset indent
293.It Va 18
294SACK enabled indicator. 1 if SACK enabled, 0 otherwise.
295.El
296.Bl -tag -offset indent
297.It Va 19
298The current state of the TCP flags for the flow.
299See
300.Aq Pa netinet/tcp_var.h
301for information about the various flags.
302.El
303.Bl -tag -offset indent
304.It Va 20
305The current retransmission timeout length for the flow, in units of HZ, where HZ
306is the kernel's tick timer.
307Divide by HZ to get the timeout length in seconds. HZ is reported in the
308enable log message.
309.El
310.Bl -tag -offset indent
311.It Va 21
312The current size of the socket send buffer in bytes.
313.El
314.Bl -tag -offset indent
315.It Va 22
316The current number of bytes in the socket send buffer.
317.El
318.Bl -tag -offset indent
319.It Va 23
320The current size of the socket receive buffer in bytes.
321.El
322.Bl -tag -offset indent
323.It Va 24
324The current number of bytes in the socket receive buffer.
325.El
326.Bl -tag -offset indent
327.It Va 25
328The current number of unacknowledged bytes in-flight.
329Bytes acknowledged via SACK are not excluded from this count.
330.El
331.Bl -tag -offset indent
332.It Va 26
333The current number of segments in the reassembly queue.
334.El
335.Pp
336The third type of log message is written to the file when the module is disabled
337and ceases collecting data from the running kernel.
338The text below shows an example module disable log.
339The fields are tab delimited key-value pairs which provide statistics about
340operations since the module was most recently enabled.
341.Bd -literal -offset indent
342disable_time_secs=1238556197    disable_time_usecs=933607 \\
343num_inbound_tcp_pkts=356    num_outbound_tcp_pkts=627 \\
344total_tcp_pkts=983    num_inbound_skipped_pkts_malloc=0 \\
345num_outbound_skipped_pkts_malloc=0    num_inbound_skipped_pkts_mtx=0 \\
346num_outbound_skipped_pkts_mtx=0    num_inbound_skipped_pkts_tcb=0 \\
347num_outbound_skipped_pkts_tcb=0    num_inbound_skipped_pkts_icb=0 \\
348num_outbound_skipped_pkts_icb=0    total_skipped_tcp_pkts=0 \\
349flow_list=172.16.7.28;22-172.16.2.5;55931,
350.Ed
351.Pp
352Field descriptions are as follows:
353.Bl -tag -offset indent
354.It Va disable_time_secs
355Time at which the module was disabled, in seconds since the UNIX epoch.
356.El
357.Bl -tag -offset indent
358.It Va disable_time_usecs
359Time at which the module was disabled, in microseconds since disable_time_secs.
360.El
361.Bl -tag -offset indent
362.It Va num_inbound_tcp_pkts
363Number of TCP packets that traversed up the network stack.
364This only includes inbound TCP packets during the periods when
365.Nm
366was enabled.
367.El
368.Bl -tag -offset indent
369.It Va num_outbound_tcp_pkts
370Number of TCP packets that traversed down the network stack.
371This only includes outbound TCP packets during the periods when
372.Nm
373was enabled.
374.El
375.Bl -tag -offset indent
376.It Va total_tcp_pkts
377The summation of num_inbound_tcp_pkts and num_outbound_tcp_pkts.
378.El
379.Bl -tag -offset indent
380.It Va num_inbound_skipped_pkts_malloc
381Number of inbound packets that were not processed because of failed malloc() calls.
382.El
383.Bl -tag -offset indent
384.It Va num_outbound_skipped_pkts_malloc
385Number of outbound packets that were not processed because of failed malloc() calls.
386.El
387.Bl -tag -offset indent
388.It Va num_inbound_skipped_pkts_mtx
389Number of inbound packets that were not processed because of failure to add the
390packet to the packet processing queue.
391.El
392.Bl -tag -offset indent
393.It Va num_outbound_skipped_pkts_mtx
394Number of outbound packets that were not processed because of failure to add the
395packet to the packet processing queue.
396.El
397.Bl -tag -offset indent
398.It Va num_inbound_skipped_pkts_tcb
399Number of inbound packets that were not processed because of failure to find the
400TCP control block associated with the packet.
401.El
402.Bl -tag -offset indent
403.It Va num_outbound_skipped_pkts_tcb
404Number of outbound packets that were not processed because of failure to find
405the TCP control block associated with the packet.
406.El
407.Bl -tag -offset indent
408.It Va num_inbound_skipped_pkts_icb
409Number of inbound packets that were not processed because of failure to find the
410IP control block associated with the packet.
411.El
412.Bl -tag -offset indent
413.It Va num_outbound_skipped_pkts_icb
414Number of outbound packets that were not processed because of failure to find
415the IP control block associated with the packet.
416.El
417.Bl -tag -offset indent
418.It Va total_skipped_tcp_pkts
419The summation of all skipped packet counters.
420.El
421.Bl -tag -offset indent
422.It Va flow_list
423A CSV list of TCP flows that triggered data log messages to be generated since
424the module was loaded.
425Each flow entry in the CSV list is
426formatted as
427.Qq local_ip;local_port-foreign_ip;foreign_port .
428If there are no entries in the list (i.e. no data log messages were generated),
429the value will be blank.
430If there is at least one entry in the list, a trailing comma will always be
431present.
432.El
433.Pp
434The total number of data log messages found in the log file for a module
435enable/disable cycle should equate to total_tcp_pkts - total_skipped_tcp_pkts.
436.Sh IMPLEMENTATION NOTES
437.Nm
438hooks into the network stack using the
439.Xr pfil 9
440interface.
441In its current incarnation, it hooks into the AF_INET/AF_INET6 (IPv4/IPv6)
442.Xr pfil 9
443filtering points, which means it sees packets at the IP layer of the network
444stack.
445This means that TCP packets inbound to the stack are intercepted before
446they have been processed by the TCP layer.
447Packets outbound from the stack are intercepted after they have been processed
448by the TCP layer.
449.Pp
450The diagram below illustrates how
451.Nm
452inserts itself into the stack.
453.Bd -literal -offset indent
454----------------------------------
455           Upper Layers
456----------------------------------
457    ^                       |
458    |                       |
459    |                       |
460    |                       v
461 TCP in                  TCP out
462----------------------------------
463    ^                      |
464    |________     _________|
465            |     |
466            |     v
467           ---------
468           | SIFTR |
469           ---------
470            ^     |
471    ________|     |__________
472    |                       |
473    |                       v
474IPv{4/6} in            IPv{4/6} out
475----------------------------------
476    ^                       |
477    |                       |
478    |                       v
479Layer 2 in             Layer 2 out
480----------------------------------
481          Physical Layer
482----------------------------------
483.Ed
484.Pp
485.Nm
486uses the
487.Xr alq 9
488interface to manage writing data to disk.
489.Pp
490At first glance, you might mistakenly think that
491.Nm
492extracts information from
493individual TCP packets.
494This is not the case.
495.Nm
496uses TCP packet events (inbound and outbound) for each TCP flow originating from
497the system to trigger a dump of the state of the TCP control block for that
498flow.
499With the PPL set to 1, we are in effect sampling each TCP flow's control block
500state as frequently as flow packets enter/leave the system.
501For example, setting PPL to 2 halves the sampling rate i.e. every second flow
502packet (inbound OR outbound) causes a dump of the control block state.
503.Pp
504The distinction between interrogating individual packets vs interrogating the
505control block is important, because
506.Nm
507does not remove the need for packet capturing tools like
508.Xr tcpdump 1 .
509.Nm
510allows you to correlate and observe the cause-and-affect relationship between
511what you see on the wire (captured using a tool like
512.Xr tcpdump 1 Ns )
513and changes in the TCP control block corresponding to the flow of interest.
514It is therefore useful to use
515.Nm
516and a tool like
517.Xr tcpdump 1
518to gather the necessary data to piece together the complete picture.
519Use of either tool on its own will not be able to provide all of the necessary
520data.
521.Pp
522As a result of needing to interrogate the TCP control block, certain packets
523during the lifecycle of a connection are unable to trigger a
524.Nm
525log message.
526The initial handshake takes place without the existence of a control block and
527the final ACK is exchanged when the connection is in the TIMEWAIT state.
528.Pp
529.Nm
530was designed to minimise the delay introduced to packets traversing the network
531stack.
532This design called for a highly optimised and minimal hook function that
533extracted the minimal details necessary whilst holding the packet up, and
534passing these details to another thread for actual processing and logging.
535.Pp
536This multithreaded design does introduce some contention issues when accessing
537the data structure shared between the threads of operation.
538When the hook function tries to place details in the structure, it must first
539acquire an exclusive lock.
540Likewise, when the processing thread tries to read details from the structure,
541it must also acquire an exclusive lock to do so.
542If one thread holds the lock, the other must wait before it can obtain it.
543This does introduce some additional bounded delay into the kernel's packet
544processing code path.
545.Pp
546In some cases (e.g. low memory, connection termination), TCP packets that enter
547the
548.Nm
549.Xr pfil 9
550hook function will not trigger a log message to be generated.
551.Nm
552refers to this outcome as a
553.Qq skipped packet .
554Note that
555.Nm
556always ensures that packets are allowed to continue through the stack, even if
557they could not successfully trigger a data log message.
558.Nm
559will therefore not introduce any packet loss for TCP/IP packets traversing the
560network stack.
561.Ss Important Behaviours
562The behaviour of a log file path change whilst the module is enabled is as
563follows:
564.Bl -enum
565.It
566Attempt to open the new file path for writing.
567If this fails, the path change will fail and the existing path will continue to
568be used.
569.It
570Assuming the new path is valid and opened successfully:
571.Bl -dash
572.It
573Flush all pending log messages to the old file path.
574.It
575Close the old file path.
576.It
577Switch the active log file pointer to point at the new file path.
578.It
579Commence logging to the new file.
580.El
581.El
582.Pp
583During the time between the flush of pending log messages to the old file and
584commencing logging to the new file, new log messages will still be generated and
585buffered.
586As soon as the new file path is ready for writing, the accumulated log messages
587will be written out to the file.
588.Sh EXAMPLES
589To enable the module's operations, run the following command as root:
590sysctl net.inet.siftr.enabled=1
591.Pp
592To change the granularity of log messages such that 1 log message is
593generated for every 10 TCP packets per connection, run the following
594command as root:
595sysctl net.inet.siftr.ppl=10
596.Pp
597To change the log file location to /tmp/siftr.log, run the following
598command as root:
599sysctl net.inet.siftr.logfile=/tmp/siftr.log
600.Sh SEE ALSO
601.Xr alq 9 ,
602.Xr pfil 9
603.Xr sysctl 8 ,
604.Xr tcp 4 ,
605.Xr tcpdump 1 ,
606.Sh ACKNOWLEDGEMENTS
607Development of this software was made possible in part by grants from the
608Cisco University Research Program Fund at Community Foundation Silicon Valley,
609and the FreeBSD Foundation.
610.Sh HISTORY
611.Nm
612first appeared in
613.Fx 7.4
614and
615.Fx 8.2 .
616.Pp
617.Nm
618was first released in 2007 by Lawrence Stewart and James Healy whilst working on
619the NewTCP research project at Swinburne University of Technology's Centre for
620Advanced Internet Architectures, Melbourne, Australia, which was made possible
621in part by a grant from the Cisco University Research Program Fund at Community
622Foundation Silicon Valley.
623More details are available at:
624.Pp
625http://caia.swin.edu.au/urp/newtcp/
626.Pp
627Work on
628.Nm
629v1.2.x was sponsored by the FreeBSD Foundation as part of
630the
631.Qq Enhancing the FreeBSD TCP Implementation
632project 2008-2009.
633More details are available at:
634.Pp
635http://www.freebsdfoundation.org/
636.Pp
637http://caia.swin.edu.au/freebsd/etcp09/
638.Sh AUTHORS
639.An -nosplit
640.Nm
641was written by
642.An Lawrence Stewart Aq lstewart@FreeBSD.org
643and
644.An James Healy Aq jimmy@deefa.com .
645.Pp
646This manual page was written by
647.An Lawrence Stewart Aq lstewart@FreeBSD.org .
648.Sh BUGS
649Current known limitations and any relevant workarounds are outlined below:
650.Bl -dash
651.It
652The internal queue used to pass information between the threads of operation is
653currently unbounded.
654This allows
655.Nm
656to cope with bursty network traffic, but sustained high packet-per-second
657traffic can cause exhaustion of kernel memory if the processing thread cannot
658keep up with the packet rate.
659.It
660If using
661.Nm
662on a machine that is also running other modules utilising the
663.Xr pfil 9
664framework e.g.
665.Xr dummynet 4 ,
666.Xr ipfw 8 ,
667.Xr pf 4 Ns ,
668the order in which you load the modules is important.
669You should kldload the other modules first, as this will ensure TCP packets
670undergo any necessary manipulations before
671.Nm
672.Qq sees
673and processes them.
674.It
675There is a known, harmless lock order reversal warning between the
676.Xr pfil 9
677mutex and tcbinfo TCP lock reported by
678.Xr witness 4
679when
680.Nm
681is enabled in a kernel compiled with
682.Xr witness 4
683support.
684.It
685There is no way to filter which TCP flows you wish to capture data for.
686Post processing is required to separate out data belonging to particular flows
687of interest.
688.It
689The module does not detect deletion of the log file path.
690New log messages will simply be lost if the log file being used by
691.Nm
692is deleted whilst the module is set to use the file.
693Switching to a new log file using the
694.Em net.inet.siftr.logfile
695variable will create the new file and allow log messages to begin being written
696to disk again.
697The new log file path must differ from the path to the deleted file.
698.It
699The hash table used within the code is sized to hold 65536 flows.  This is not a
700hard limit, because chaining is used to handle collisions within the hash table
701structure.
702However, we suspect (based on analogies with other hash table performance data)
703that the hash table look up performance (and therefore the module's packet
704processing performance) will degrade in an exponential manner as the number of
705unique flows handled in a module enable/disable cycle approaches and surpasses
70665536.
707.It
708There is no garbage collection performed on the flow hash table.
709The only way currently to flush it is to disable
710.Nm .
711.It
712The PPL variable applies to packets that make it into the processing thread,
713not total packets received in the hook function.
714Packets are skipped before the PPL variable is applied, which means there may be
715a slight discrepancy in the triggering of log messages.
716For example, if PPL was set to 10, and the 8th packet since the last log message
717is skipped, the 11th packet will actually trigger the log message to be
718generated.
719This is discussed in greater depth in CAIA technical report 070824A.
720.It
721At the time of writing, there was no simple way to hook into the TCP layer
722to intercept packets.
723.Nm Ap s
724use of IP layer hook points means all IP
725traffic will be processed by the
726.Nm
727.Xr pfil 9
728hook function, which introduces minor, but nonetheless unnecessary packet delay
729and processing overhead on the system for non-TCP packets as well.
730Hooking in at the IP layer is also not ideal from the data gathering point of
731view.
732Packets traversing up the stack will be intercepted and cause a log message
733generation BEFORE they have been processed by the TCP layer, which means we
734cannot observe the cause-and-affect relationship between inbound events and the
735corresponding TCP control block as precisely as could be.
736Ideally,
737.Nm
738should intercept packets after they have been processed by the TCP layer i.e.
739intercept packets coming up the stack after they have been processed by
740tcp_input(), and intercept packets coming down the stack after they have been
741processed by tcp_output().
742The current code still gives satisfactory granularity though, as inbound events
743tend to trigger outbound events, allowing the cause-and-effect to be observed
744indirectly by capturing the state on outbound events as well.
745.It
746The
747.Qq inflight bytes
748value logged by
749.Nm
750does not take into account bytes that have been
751.No SACK Ap ed
752by the receiving host.
753.It
754Packet hash generation does not currently work for IPv6 based TCP packets.
755.It
756Compressed notation is not used for IPv6 address representation.
757This consumes more bytes than is necessary in log output.
758.El
759