Hi Alan,
You seem to have picked up the ball and run with it
quite well, so I think what PSARC needs now is to see
a new proposal with all of the additions and other
changes that have been discussed.
On structuring the document, my thoughts on this are
as follows:
1) you're doing design and architecture work that
should be able to be picked up by others and used
to structure further transport layer probes, so
fleshing out the proposal some more could be
beneficial in the future to those that follow and want
to implement dtrace probes for future networking
protocols;
2) now that you've expanded on each of the two protocols,
you might like to think about whether it should be one
PSARC case or two (I don't think anyone would mind
if a newer one had the same timeout as the older one).
Feel free to ignore this if you like :)
3) as an exercise for yourself, consider how a new protocol
such as RDP (Reliable Datagram Protocl) or ICMP would
be mapped into dtrace using what you're introducing as
the basis of a design for them.
4) you might like to think about whether or not the
probes being introduced fit into different categories.
Two such categories might be socket and protocol. For
example, the TCP state changes are effectively invisible
to the socket and represent internal operations of the
protocol. Probes such as socket-open and socket-closed
are at a completely different level of abstraction to
the TCP state change one yet they're part of the same
dtrace provider.
I suppose (4) calls into question whether it is the correct
architecture to have socket probes per protocol or whether
there should be a socket dtrace provider. What are the trade-
offs involved in pushing the socket probes into a socket
provider vs a protocol provider? I don't want to ask to
redesign what's been proposed but I do think there needs to
be more thought given to how dtrace interacts with sockets
and network protocols than just putting some probes in where
we think it will be interesting and help us achieve specific
goals. For example, should we be reviewing socket:tcp::open
and socket:udp::closed rather than tcp:::socket-open and
udp:::socket-closed? Does every protocol need to introduce
its own ":::socket-open" and ":::socket-closed" or should
it be enough to have just "socket:::open" and "socket:::closed"?
Are there elements of the design and how you're using that
implementation that would suffer from a different approach
to dtrace for TCP and UDP sockets? These are my questions
to you and the folks you're working with on this...
When I look at the original proposal, I see some interesting
work but I don't really see a lot of architecture (just some
named interfaces) in a space where there is room for good
architecture to be designed and introduced (given time.)
I think if the documentation is appropriately structured
that we can get some real architecture out of it ;)
That's my fast track opinion fodder for this case :)
Cheers,
Darren
On 04/02/10 03:53, Alan Maguire wrote:
Sorry to be following up again, but I think it would
be helpful if I make a specific proposal wrt the
additional probes required, especially the tcp
close-related probes. 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
as initiation of a graceful shutdown or in response
to a shutdown request from a peer.
tcp:::close-established
Fires when an ACK is received to a previously-sent
FIN segment. This probe firing may simply indicate
a half-close - i.e. the peer connection may not close
from it's side.
tcp:::close-accepted
Fires when a FIN segment is received from a peer.
If tcp:::close-accepted and tcp:::close-established
fire, the connection has shut down both sides but
may linger of course.
tcp:::reset-request
Fires when a RST segment is sent to a peer connection
to forcibly close (e.g. when we close and SO_LINGER is
set to 0). This is distinguished from a RST|ACK segment,
the sending of which is covered by the tcp:::accept-refused
probe.
tcp:::reset-accepted
Fires when a RST segment is received from a peer
connection.
With these probes in hand, we can ask questions like:
- how long do connections take to close down?
- which side initiated the close?
- how many half-closed connections are there?
- how many connections close gracefully? how many
close forcefully?
etc.
The naming of the probes is consistent with the
connect-* and accept-* probes, and like those
probes they supply the IP/TCP headers associated
with the control segment they represent. The
addition of these probes also means we have
coverage for all the connection control segments
(SYN, FIN, RST) and their related acknowledgments.
We should also add:
tcp:::socket-opened
Fires when a TCP socket is opened.
tcp:::socket-closed
Fires when a TCP socket is closed.
In addition to these, we also have the
tcp:::state-change probe which covers the
"closed" pseudo-state.
For UDP, as Darren suggests, it would be helpful
to have equivalents for the
accept-refused/connect-refused probes so that
users can detect cases where they attempt
to connect to nonexistent services. I think it
may make sense to stay away from
connect-refused/accept-refused for names as
these terms imply a connection, so I suggest
(the rather unwieldy):
udp:::port-unreachable-send
Fires when an ICMP port unreachable message
is sent in response to a UDP datagram heading
for a port with no UDP server. It is true that
an ICMP DTrace provider should cover this event,
but it might be helpful to have a probe point
within the UDP provider for such an event also.
udp:::port-unreachable-receive
Fires when an ICMP port unreachable message
is received in response to a UDP datagram.
Thanks!
Alan
On 01/04/2010 20:53, Alan Maguire wrote:
Apologies, I misstated something below....
On 01/04/2010 18:30, Alan Maguire wrote:
On 01/04/2010 08:33, Darren Reed wrote:
On 03/31/10 22:49, Adam Leventhal wrote:
Darren,
I'm not sure that enough detail is provided for
this to be "automatic" and there is also the problem
of the missing UDP probes... see below.
If you scroll down, you'll find the udp provider probes listed.
If we do simple trackng of accept-established and
connect-established, we're able to count how many
active connections there are but to properly adjust
the counter when things close requires tracking
state-change and understanding enough of TCP
to know how to adjust your stats correctly.
True. With respect to tcp close issues, I guess there's
a few ways to handle close events:
1. a socket-oriented close probe "tcp:::socket-close" (and
for consistency tcp:::socket-open). Adding these seems
reasonable to me, especially given the fact that it would
be consistent with the udp provider, as you note below.
2. a close probe in the style of the connect-* and
accept-* probes - "tcp:::connection-closed" perhaps?
This could fire when tcp reaches the fictional
closed state for one of the following reasons:
- when the TIME_WAIT timeout on a closing connection
has expired
- when we receive the LAST_ACK for a passive close
- when we time out in SYN_SENT state
- when we send or receive a RST segment aborting
the connection, or we receive a RST|ACK.
3. a state-change probe for the closed state
(tcp:::state-change where the new state argument is
"state-closed"). This was discussed a while back, and the
consensus was not to use the closed state since it is described
as fictional in RFC793. Jim describes this here:
http://mail.opensolaris.org/pipermail/dtrace-discuss/2006-September/002456.html
So my proposal would be to add 1 and 2 above to the
provider specification. Does this seem reasonable?
Actually, we already have 3 - tcp:::state-change where
the new state is "state-closed". Apologies for the confusion -
I was writing from memory. So the question is if we should
add 1 and 2 I guess.
Alan
_______________________________________________
opensolaris-arc mailing list
[email protected]
