There’s a fairly small and well defined project that might help your efforts, the robotics hackathon, and Monty in general. Basically, it would involve working with the Monty developers to implement and test a multi-process and multi-platform API (i.e., network fabric) for the CMP.
Here are some possible criteria:
- plays nicely with the existing Monty code base
- plays nicely with other platforms (e.g., Elixir)
- supports optional tracing of message activity
- supports “secure by default” communication
- has an integrated test suite on each platform
- and a pony…
For more information, see my response to @rolly over in Your Robot Expertise is Requested!
One of our goals is for Monty to interoperate with different modules and policies. Your work will drive the Monty code closer to that goal. Additionally, one of the reasons for open-sourcing was to facilitate experimentation. I, for one, am curious about what you’ll create and can work with you to ensure that things interoperate. I think keeping in mind the high-level Architecture Overview will help keep things on track.
Regarding the Monty codebase, I am drafting a refactoring of the interaction between data loaders, the motor system, and policies. You may find the description of the current state helpful, and that’s where I intend to document the upcoming changes before making them. Below is the partial roadmap related to policies, and the RFC mentioned above is part of the work labeled “Injection #1: Move motor policies out of the data loaders.” (The dashed boxes are placeholders to be filled in later)
1 Like
Can you provide an idea of the current situation regarding CMP usage? For example, how many places in Monty would need to be modified in order to fit in a common messaging API?
@tslominski thanks I took a look at the work you are doing and it is helpful. I think the issue is that I am looking at a set of use cases where there are multiple static sensors getting time series information and trying to learn about the environment. Networking is one use case, weather stations could be another as well as any other environmental monitoring or time series system.
FWIW, there are a number of “integrations” for OpenTelemetry, some of which can handle time series data. There are also a number of time-series databases (e.g., Prometheus) that claim to play nicely with OpenTelemetry.
Hi @Rich_Morin, if this was for me, I haven’t looked through the code with this framing in mind, so I don’t have a summary.
Thanks @Doonhammer for your interest in working with Monty in this setting, it definitely sounds interesting.
It’s worth noting that Monty needs to perform some kind of movement (such as through abstract spaces) to benefit from its unique attributes, given that it is at its core a sensorimotor system. On the other hand, while older Numenta algorithms like HTM can be used for time-series data, supporting such data is actually a work in progress for Monty. If you look at our current datasets, you will therefore see that they consist of static objects, but the Monty system is constantly moving. We’re hoping to support Monty learning dynamic, time-varying objects soon, but it’s on the 6-12 month timescale at the earliest.
I think it would be helpful if you could walk through how you see the Thousand Brains Theory mapping onto the problem you are dealing with. Reference frames can be used for encoding abstract and concrete network spaces (interconnected nodes, their geolocation, etc.), but without any movement through a space of some kind, I’m struggling to see how Monty will bring a major benefit to your problem setup. For example, Monty could be setup to attend to different sensors at a given point in time, if focusing computational resources would provide benefits from a network-security point of view. This would be similar to the non-physical movement that occurs in our visual field when we attend to a region without moving our eyes.
Alternatively you could imagine how a security engineer might (although I know very little about this) navigate through a series of directories if they are concerned that some malicious activity has taken place. Perhaps examining every binary file for evidence of tampering by a 3rd party is infeasible within a given period of time, and so requires a principled, hypothesis-driven search based on a learned model of the network and its contents. This is definitely not my area of expertise, but hopefully this gives some sense of what I mean by movement.
Once I better understand any mapping between the Thousand Brains Theory and your problem setup, I can suggest how Monty might be best applied if appropriate.
3 Likes
@nleadholm thanks for the detailed reply and analysis. Let me try and answer your questions and try and provide more context.
The reason I looked at Monty was after reading @jhawkins 's books and realizing the current approach to anomaly detection in general using machine learning, while it works well in many cases, requires a lot of human work and is cumbersome in many cases.
In my (maybe naive ) opinion what is happening is the human brain is getting a lot of numbers and looking for patterns and anti-patterns. Computers are used intensively to crunch and summarize data, but in the end a human is in the loop to learn and determine if the data is good or bad. I saw this similar to the TBT where the numbers are RGB + other metadata. In TBT currently there are poses involved but I thought this is similar to looking at the data from different sensors.
To take my security example the object_id becomes the network 5-Tuple (srcIP, srcPort, dstIP, dstPort, protocol) the data/properties are extracted from each packet and at different locations (different poses?). These are the steps an engineer goes through, engineers with more experience (learning ?) can see problems faster. So from a math POV is this very different from looking at an object from multiple POV, assembling the data and deciding it is or is not a cup? The other question I would have if Monty recognizes and object as a cup would it recognize a chipped or cracked cup as a new object or a related object?
As TBT is trying to be a better model of the human brain I was hoping that it could do a lot of the heavy lifting in these types of problems, i.e. learn to become an expert by building up experience as humans do…
Does this make sense - let me know and if not I can try again.
Thanks
John
1 Like
Okay a quick attempt at answering @nleadholm question in @Doonhammer domain. I know both of you and a little of both fields so here goes.
To make it specific I first need to discard some things. Let’s for the moment not try assign moral values to network flows. Bad packets and Bad flows are pretty hard to think about in a self learning system so lets simplify the problem to just tackle the still interesting problem of sorting network flows by type/behaviour.
Next lets make it more specific to say we have a couple of flows, all the flows are over HTTPS so not simple as just looking in the packet but under the cover we have three very different things, one is a voice call, one is a web page application, and one is a file download.
Now for those who do not live in breath network a networking professional can look at those flows and guess them apart and here is how (don’t nitpick the detail of this I am just doing it to give some example of think we can SAMPLE to tell things apart:
- the voice session will have a pattern of responses at specific packet sizes at the start.
- the voice session will have small packets at regular intervals, but typically with silence suppression etc not all the time
- The app will have a bunch of packets containing images and programs at the start and then, and then the behaviour of the packets is very dependent on what the app is doing but the same app will do similar patterns of how much data from which size.
- The file transfer will have big packets streaming from the source and small acknowledgements going up.
Now with EBGP one can sample every packet in the edge. The problem is you can keep all the data for all the things. So lets guess the sensor behaviour to be it samples the first packet. Creates an object id… and gets back a couple of possible hypotheses of what the flow could be.
So the first thing we notices is that it is HTTPS so the hypotheses are voice, app or file transfer. To tell the difference between a file transfer and a voice session it sample the next response packet from the server if it is big we eliminate voice session. To tell between App and File Transfer we watch the next 2000 packets and see if the packet size from the server is tending to be a fixed size… and that the responses are short acknowledgements.
So the non-physical movement is sample strategies for proving a hypothesis of a flow.
Networking flows as objects have one large simplification over the visual domain which is we really can tell when they are one object (like perfect masks in visual domain) and one large complexity which is we cannot (because of speed and storage) take sample retrospectively. In the visual domain it would be a little a like thrown soft toy into a basket, you only get a limited number of sample before it disappears.
Finally I did simplify a few things so let’s acknowledge those as well.
- I simplified that we actually can take actions in networks which will result in application layer behaviours that could prove/disprove hypothesis
- You absolutely will want to have a consistent flow id across multiple sample points in a network. A vision analogy would be you have a creature with ten eyes on stalks all looking at the same object from different points of few and even possibly sampling different things.
- The space of behaviour recognition of packet flows is pretty rich, involving latency, and many other things I simplified to size and size and packet counts just to make it easier too picture and often where humans start.
-Ric
4 Likes
Great to see you on the forums @ricpruss and thanks for adding some insight.
As. Ric brings up, different sampling strategies could be a form of movement, assuming these are different based on the working hypothesis. So if the system/network engineer would act differently (examine different packets, examine them in different ways, etc.) based on the working hypothesis, then this is sensorimotor. It’s important to note however that having different predictions coupled with passive sensing is not sufficient for it to be sensorimotor - in that case, a passive form of predictive learning like HTM would be sufficient. Hope that makes sense @Doonhammer , happy to delve into this further.
To answer your other question @Doonhammer about the chipped/cracked cup, this depends. In general, we would expect/desire the system to develop both generalizing, and more specific representations. So one column might recognize a cup regardless of whether it has a chip or crack, whereas another column/representation could emerge for the specific instance of a chipped cup. Practically speaking, right now it would learn these as separate objects if we provided a supervised label. If Monty did unsupervised learning today, it would probably merge them, but having more nuanced unsupervised learning is something we are working on.
1 Like
