On Fri, Apr 02, 2010 at 11:53:33AM +0100, Alan Maguire wrote: > [...]. I think adding the following > set of probes to the original proposal should hopefully > address shortcomings in this area in a manner > consistent with the connect-* and accept-* probes: > > tcp:::close-request > > Fires when a FIN segment is sent to a peer, either > [...] > > tcp:::close-established > > Fires when an ACK is received to a previously-sent > FIN segment. This probe firing may simply indicate > [...] > > tcp:::close-accepted > > Fires when a FIN segment is received from a peer. > [...] > > tcp:::reset-request > > Fires when a RST segment is sent to a peer connection > [...] > > tcp:::reset-accepted > > [...]
I'd rather see probes named and specified unambiguously after: - TCP state transitions (where the name of the probe that fires represents the new state of a connection and the old state is in some argument). State names should be taken from the standard: CLOSED, LISTEN, SYN_RCVD, SYN_SENT, EXTABLISHED, CLOSE_WAIT, LAST_ACK, FIN_WAIT_1, CLOSING, FIN_WAIT_2, TIME_WAIT. You might have just one probe, with the old and new states being arguments. - TCP "signals": locally-initiated close/shutdown, active open (connect), passive open (listen), receipt of RST, SYN, SYN-ACK, FIN, FIN-ACK, and ACK of a SYN-ACK, FIN, or FIN-ACK. These should also be named after the terminology used in the standard. Whether a signal is "accepted" or "rejected" (either dropped silently or responded to via a TCP or ICMP message) should be an argument of the TCP signals probes. You might have just one probe, with the signal being an argument. (Or two probes, one for locally generated signals and one for remote signals.) - TCP options? A probe per-option? Or let the caller parse options data passed as arguments to the relevant probes? TCP options can have a huge impact on perfomance (think of SACK, window scaling, PAWS, ...). Arguably the options that apply to a given connection should always be available for any probes firing for any connection in at least ESTABLISHED state. - data send/receive, ACKs of data - window size changes - congestion state transitions - PMTUD events The last five are probably crucial for performance analysis. The first two could be used to test for correctness (module drops, of course), for example, as well as to measure connection establishment performance, etcetera. All are important in general. Nico -- _______________________________________________ opensolaris-arc mailing list [email protected]
