hi Nico
On 02/04/2010 17:48, Nicolas Williams wrote:
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.
Yep - see the tcp:::state-change probe in the original
proposal. The above were additional probes, to cover
the points Darren raised.
- 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.)
These are the tcp:::connect-request, tcp:::connect-established,
tcp:::connect-refused (sending a SYN, receiving the final
ACK in the three-way handshake, receiving a RST|ACK);
tcp:::accept-established and tcp:::accept-refused (received a
SYN and responding with SYN|ACK, received a SYN and
responding with a RST|ACK); tcp:::close-request,
tcp:::close-established and tcp:::close-accepted (sending a FIN,
receiving an ACK to a FIN, receiving a FIN).
- 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.
I've tried to make a certain amount of this state available via
the tcpsinfo_t translation of the tcp_t.
- data send/receive, ACKs of data
Yep, see the tcp:::send and tcp:::receive probes.
- window size changes
These are available at the various probe points,
either via the tcpsino_t structure (which is a translated
version of the tcp_t), or via the translated tcp headers
which are arguments to the tcp:::send/receive
probes.
- congestion state transitions
These are available at the tcp:::send/tcp:::receive
probe points by examining the tcp flags and headers,
but it might be useful to add tcp_cwnd to the tcpsinfo_t
translation of the tcp_t.
- PMTUD events
There's already a SDT probe (tcp_update_pmtu) for
PATH MTU update events, but again it might be useful
to make the MSS is available via the tcpsinfo_t translator
of the tcp_t.
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.
Understood. I think it would be a good idea to augment
the fields in the tcpsinfo_t with the additional information.
Thanks!
Alan
_______________________________________________
opensolaris-arc mailing list
[email protected]
