Subject: Process id in UDP/TCP mibs?

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 May 2006 09:55:49 -0700

Both RFC 4113 (UDP MIB) and RFC 4022 (TCP MIB) have a process ID for
each endpoint (udpEndpointProcess and tcpConnectionProcess).

Was there any discussion how this can be implemented? Due to fork etc
there can be more than one process which has a socket open and only one
pid fits in the MIB.

In addition, Solaris and BSD AFAIK doesn't let the socket layer track
the current (set of) processes that have the socket open - only the
first open (when the socket is created) and the last close results in
the socket layer being called. Thus the socket layer can only track the
process that can created the socket - a sequence of socket+fork+exit
would have that process go away but the socket remain open.

Note that there are tools like lsof that allows showing the open files 
for processes, including the TCP and UDP information for the file 
descriptors that are socket. But that tool can handle a many-to-one 
relationship from processes to sockets/endpoints, since it starts from 
the process.
The MIBs attempt to do this from the endpoint/socket to the process, 
which is what is problematic.

Do we need to deprecate or clarify these objects?

    Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 May 2006 08:36:45 +0200

> Do we need to deprecate or clarify these objects?

While we can work out details such that these objects become
implementable with a well defined semantic, I have the feeling that
the result would not be terrible useful for management applications.

The motivation for these objects was clearly to allow management
applications to find the process(es) which deal with a given
connection endpoint and as you write this can't really be achieved by
adding more language to the DESCRIPTION clauses.

So my preference would be to deprecate them since what we really would
need is a n:m mapping table between process ids and transport endpoints.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 12 May 2006 13:51:57 -0700

> need is a n:m mapping table between process ids and transport endpoints.

Any other comments?

If not, how do we go about deprecating them?

    Erik

eived: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FeecE-0001Al-P9
	for [email-masked]; Fri, 12 May 2006 16:52:02 -0400
Date: Fri, 12 May 2006 13:51:57 -0700
From: Erik Nordmark <[email-masked]>
To: Erik Nordmark <[email-masked]>, IPv6 Mailing List <[email-masked]>, 
	Rao Shoaib <[email-masked]>
Cc: 
Subject: Re: Process id in UDP/TCP mibs?

> need is a n:m mapping table between process ids and transport endpoints.

Any other comments?

If not, how do we go about deprecating them?

    Erik

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 13 May 2006 09:44:07 +0200

> If not, how do we go about deprecating them?

On the technical side, there is a slight problem with deprecating
udpEndpointProcess and tcpListenerProcess since these objects are the
only readable column of the underlying tables and hence the whole
table becomes not-accessible. And changing the MAX-ACCESS is not
allowed by the SMIv2 rules - so we essentially would have to create
new tables...

/js