NFD » ndn-tools

Regarding the feature itself, I remember from a recent call that there was some fairly strong disagreement on whether ping is the best way to accomplish your goal. What this feature would tell you is essentially whether the app prefix is registered or not in the local NFD, but doesn't say anything about the application's health or anything else. What you really want is an app monitoring platform, and ping is not the right tool for that. One simple solution that was suggested at the same call was to try fetching a small piece of (static) data from the producer and see if it responds.

Davide Pesavento wrote in #note-2:

One simple solution that was suggested at the same call was to try fetching a small piece of (static) data from the producer and see if it responds.

To elaborate a bit more: the exact name used for this would necessarily have to be app-specific, but the actual realization of the mechanism can be delegated to the library (e.g., using a fake piece of data created specifically for "pinging" purposes), or it could be actual application content that is guaranteed to exist at a given name.

I don't know what kind of ping you're using but ICMP does not have the concept of port number, so no, this is not possible in IP/ICMP.

Right. I meant applications like hPing and the capability of checking a specific port in IP.

I remember from a recent call that there was some fairly strong disagreement on whether ping is the best way to accomplish your goal.

I don't recall any strong disagreement. If you remember any, share it, please.

What this feature would tell you is essentially whether the app prefix is registered or not in the local NFD, but doesn't say anything about the application's health or anything else.

So neither tools like hPing. The task is simply about whether the remote NFD serves a given nameprefix or not. Based on my understanding as far as there remote NFD has a registered nameprefix it means there is an app running on the machine that serves that nameprefix.
A monitoring tool would be highly appreciated but it does not void the applicability of this feature.

One simple solution that was suggested at the same call was to try fetching a small piece of (static) data from the producer and see if it responds.

Well, I do not think that this is as simple as you think. Different applications have different behaviors (e.g., consider apps that use RDR). However, this feature does not require the consumer follows different name conventions, but simply specifying the nameprefix of the app.

Chavoosh Ghasemi wrote in #note-4:

I don't know what kind of ping you're using but ICMP does not have the concept of port number, so no, this is not possible in IP/ICMP.

Right. I meant applications like (hPing)[[https://tools.kali.org/information-gathering/hping3]] and the capability of checking a specific port in IP.

IP doesn't have ports either. So this must be a transport-layer thing. But in any case, the fact that a specific tool exists in the IP world doesn't mean by itself that the same feature/mechanism makes sense in NDN.

What this feature would tell you is essentially whether the app prefix is registered or not in the local NFD, but doesn't say anything about the application's health or anything else.

So neither tools like hPing.

So what does it do then? It sounds very similar to a port scanner at this point.

The task is simply about whether the remote NFD serves a given nameprefix or not.

Then developing something based on NMF or DNMP would be much better in my opinion.

One simple solution that was suggested at the same call was to try fetching a small piece of (static) data from the producer and see if it responds.

Well, I do not think that this is as simple as you think.

It's certainly simpler than your proposal.

Different applications have different behaviors (e.g., consider apps that use RDR).

What does RDR have to do with any of this?

However, this feature does not require the consumer follows different name conventions, but simply specifying the nameprefix of the app.

You're forgetting that ndnping does rely on a naming convention already. So from this point of view the two approaches are equivalent.

I think some of the confusion here comes from the fact that the issue title is "pinging running applications" but then the proposed approach achieves something very different from that. In your last comment it actually seems that what you want is a "republishing" of the list of routes, or "querying" the RIB (or FIB?) for the existence of a prefix toward any local face.
Maybe, as a first step, you should clarify that.

the fact that a specific tool exists in the IP world doesn't mean by itself that the same feature/mechanism makes sense in NDN.

You're missing the point. The topic is about a feature not duplicating an IP tool in NDN. I just said how IP implements this feature as an example. As I mentioned in issue's description We need a way to check if a specific application is running on a remote machine.

It sounds very similar to a port scanner at this point.

hPing is a port scanner.

Then developing something based on NMF or DNMP would be much better in my opinion.

Well, agreed and not agreed. Agreed, if we already had these solutions deployed on the testbed and we could build new functionalities over them. However, I do not know about their status deployment-wise (more info on these solutions would be welcome if you have any).

You're forgetting that ndnping does rely on a naming convention already. So from this point of view the two approaches are equivalent.

Of course it does; any app follows a name convention. The point is as a consumer I do not need to form different Interest names for different applications to check their status on a remote machine. For instance, an application answers to Interests whose name carries a version number, while some others do not mandate it. As a consumer I do not want to have knowledge of what name format I have to follow to get a response from an app. I would like to solely ping its name and see whether it is running or not (this is what I am exactly proposing). Of course, we can ask the consumers to lift the heavy weight and learn about each application's name convention. But why cannot we just have a mechanism that, despite how each app's name convention is, checks the status of the app.

Chavoosh Ghasemi wrote in #note-7:

the fact that a specific tool exists in the IP world doesn't mean by itself that the same feature/mechanism makes sense in NDN.

You're missing the point. The topic is about a feature not duplicating an IP tool in NDN. I just said how IP implements this feature as an example.

"tool"... "feature"... same difference.

As I mentioned in issue's description We need a way to check if a specific application is running on a remote machine.

Well, apologies, but as I said in #note-6, the way you originally phrased the issue title, together with the ambiguous sentence "we need a way to check if a specific application is running", was really indicating something quite different to me compared to what you actually want (which is the answer to the question: is this prefix registered on that node's forwarder?)

You're forgetting that ndnping does rely on a naming convention already. So from this point of view the two approaches are equivalent.

Of course it does; any app follows a name convention. The point is as a consumer I do not need to form different Interest names for different applications to check their status on a remote machine. For instance, an application answers to Interests whose name carries a version number, while some others do not mandate it. As a consumer I do not want to have knowledge of what name format I have to follow to get a response from an app. I would like to solely ping its name and see whether it is running or not (this is what I am exactly proposing). Of course, we can ask the consumers to lift the heavy weight and learn about each application's name convention. But why cannot we just have a mechanism that, despite how each app's name convention is, checks the status of the app.

I don't think you understood my suggestion. Given an app prefix /foo/bar, the "echo responder" will be at /foo/bar/ping, completely contained within the app's namespace. The last component <ping> can be anything we agree upon, in exactly the same way that the current ndnpingserver registers /<node-prefix>/ping. It's a convention.
As an additional bonus feature, you get echo replies signed by the actual application's key. (your design makes no mention of any trust issues that may arise)

Okay, I see what you're saying. As the downside of this approach, it enforces the modification of the applications. In other words, each application must support "echoing to /<app-prefix>/ping." Right?

Chavoosh Ghasemi wrote in #note-10:

Okay, I see what you're saying. As the downside of this approach, it enforces the modification of the applications. In other words, each application must support "echoing to /<app-prefix>/ping." Right?

Yes, but the actual implementation can be entirely contained in the library (e.g., ndn-cxx) and the app just has to enable the feature by calling a function when it creates the face, e.g., face.replyToPings(true) or face.enableEchoResponder() or whatever.

This approach does not allow us to specify what machine/site is the target. Given we have two servers, one in Arizona and one in UCAL. Both of these servers serve the same nameprefix (/ndn/web). Using your approach, a consumer expresses an Interest with the name /ndn/we/ping. In this case, either of those servers might answer. Here we cannot learn if any of these two servers is down.

In contrast, my approach allows a consumer to specify the site name in the Interest name, followed by the app name. Considering the above example, the consumer can once express an Interest with the name /edu/arizona/ping/ndn/web and then /edu/ucla/ping/ndn/web. This way we can check on the status of a given application on a specific machine.

Security-wise, all Interests are signed by ndnpingserver, as the namespace we use belongs to ndnping tools (i.e., /<site-name>/ping).

No, the two approaches are pretty similar from this point of view. Just register /<site>/<app>/ping in addition to /<app>, similarly to pingserver replying to /<site>/ping/<app>.

But how? If my cert's identity is /ndn/web, then my app can only sign Data packets under this namespace. Therefore, even if my application does register /<site-name>/ndn/web/ping with the local NFD, the NFD will fail to register it with a testbed gateway. Right?

That is orthogonal, the usual rules/policies for prefix registration are not affected by this. And yes, you would need to register one extra prefix, which I'm not super happy about either, but this is a compromise. I maintain that the proper approach is to have a monitoring/measurement agent on each node that can export a number of stats and other info about the forwarder and can respond to remote queries, as I mentioned above.

By the way, another thing was mentioned when we spoke about this: moving the ping server into nfd itself, at which point that component can also respond to these "route exists?" queries with a somewhat lower overhead (no need to periodically poll nfd for the list of routes). I still find it ugly, but it would be slightly more acceptable.

That is orthogonal, the usual rules/policies for prefix registration are not affected by this.

I do not fully understand what you mean. If we need two different certs, one for /ndn/web and one for /<site-name/ndn/web, then I do not think this would be a good solution.

I maintain that the proper approach is to have a monitoring/measurement agent on each node that can export a number of stats and other info about the forwarder and can respond to remote queries, as I mentioned above.

I agree. However, as I said a monitoring/debugging platform is quite a big topic and needs collective thoughts from the community. Anyways, I do not think we will have such a thing, at least, in the near future.

By the way, another thing was mentioned when we spoke about this: moving the ping server into nfd itself, at which point that component can also respond to these "route exists?" queries with a somewhat lower overhead (no need to periodically poll nfd for the list of routes).

What I have in my mind is something like this: upon receiving a ping request by ndnpingserver it will check local NFD's FIB. It tries to find the queried app name. If the interface associated with the app name was a local face, it means there is an alive application running on the remote machine that serves the queried name; otherwise the remote machine does not have such an application.
As the procedure of checking NFD for each ping request might be expensive, ndnpingserver might set the freshness of its Data packets to a few seconds. This way, consumers who aggressively send ping requests cannot cause problem on the remote machine.