NFD

Alexander Lane wrote:

Currently, TRACE level forwarder logging in NFD provides very little in the way of actual information on the actual incoming/outgoing traffic

Well, it's not supposed to be a full packet trace...

I want to make sure there are not design reasons for not including it I'm missing before I finalize and submit this to Gerrit.

I don't think there are, but a few minor considerations for completeness:

1. Generating the full URI as opposed to just the name requires more CPU cycles.
2. The URI also shows the hop limit (if present in the interest), which changes over time, so if you're mining the logs and naively comparing whatever comes after "interest=" as a plain string, the same interest with a different hop limit will no longer match.
3. The "interest URI" is not a well-defined concept, its format is purely an implementation choice of ndn-cxx and was mainly intended for quick debugging, I guess we didn't want to "expose" it too much in NFD (using it in the forwarder logs means that anyone analyzing the logs will have to implement some sort of parser for that vaguely-defined format).

Currently, TRACE level forwarder logging in NFD provides very little in the way of actual information on the actual incoming/outgoing traffic; while knowing the name of an interest is helpful, lacking the nonce can make tracing packets through multiple nodes and applications difficult. Adding a nonce field to the logging provides more information with relatively little cost.