Task #3476
open
Design NFD instrumentation
0%
Description
Real-world application deployment, such as NDN-RTC, could significant benefit from additional real-time and post facto data on NFD behavior. To complement logging, perhaps some type of dynamic tracing could be considered, ala DTrace, http://www.brendangregg.com/dtracetoolkit.html. Insight into per-prefix behavior and packet-processing performance would be very helpful for applications like NDN-RTC.
Updated by Davide Pesavento over 8 years ago
- Start date deleted (
02/28/2016)
I can suggest LTTng (http://lttng.org/) for a Linux userspace tracing solution.
Updated by Jeff Burke over 8 years ago
My suggestion was D-Trace: http://www.nbl.fi/~nbl97/solaris/dtrace/dtt_present.pdf
Junxiao asked for more information on this.
Updated by Davide Pesavento over 8 years ago
As far as I can see, D-Trace is available only on OS X, several BSD variants, Solaris, (maybe others?) basically anything except Linux. There is this https://github.com/dtrace4linux/linux but it requires building and installing a kernel module, which severely limits its deployability IMHO.
On the other hand, LTTng is Linux-only :-/ There's also SystemTap (https://sourceware.org/systemtap/) for Linux, which looks very similar to D-Trace (at least the probe language seems to be).
@Jeff, can you describe what kind of instrumentation you need? Do you have some specific examples in mind? Does it involve adding trace points to NFD, or is detailed system/kernel-level tracing enough?
Updated by Junxiao Shi over 5 years ago
I received this question that is related to this issue.
assume there’s a need to collect some fine-grained statistics about traffic passing each router, how do we best support it in NFD? I’m thinking to use the measurement table to record the statistics, and make the information available through NFD management protocol. Also add a piece of code in the forwarding pipeline to update these statistics regardless of forwarding strategy in use. Of course this piece is optional and can be turned on by the administrator.
My original NFD design includes a "switch mirror port"-like functionality: one can send a management command to make NFD duplicate packets under a namespace to a face, and an analysis program on that face can then analyze the traffic. IncomingFaceId and timing information are indicated in NDNLP headers.
In reality, people are using tcpdump.
Having certain counters in forwarding itself is a good complement to the above approach. These counters should be universal, not specialized for an application.
Both FIB and Measurements table can store counters.
Some "cheap" counters (e.g. number of incoming Interests) can be placed in every FIB entry.
Other "expensive" counters (e.g. smoothed RTT) should be enabled by a management command, and placed in Measurements table.
Forwarding strategies are also collecting counters, and some of them should be uniformed and consolidated.
To retrieve those counters, use #4446.