NFD » ndn-cxx

Question: In the NFD changes needed for this, how does the dead nonce list work if there's no nonce an the incoming Interest? Perhaps we can just skip checking the list in that case?

how does the dead nonce list work if there's no nonce an the incoming Interest?

The easiest way is to generate a random Nonce upon entering forwarding. Then you don't need to change any other procedures.

Junxiao Shi wrote in #note-9:

how does the dead nonce list work if there's no nonce an the incoming Interest?

The easiest way is to generate a random Nonce upon entering forwarding. Then you don't need to change any other procedures.

It looks like this would already be done when checking against the dead nonce list, since that calls getNonce(). No changes to NFD needed then?

This task was only loosely defined. We should agree on the way forward before implementing/changing anything. I see at least 4 possible ways to move forward:

1. getNonce() stops generating a nonce if one isn't present, changing the return type to something like optional<Nonce>. Then either (1a) ndn-cxx generates a nonce before sending the packet or during Interest encoding, or (1b) NFD generates a nonce upon receiving a nonce-less Interest. This probably requires adding a new Interest method to explicitly generate a nonce.
2. Keep the current getNonce() semantics, disable nonce generation during Interest encoding, but keep it in Face::expressInterest(). (This is Eric's patch)
3. Same as (2) but also disable nonce generation in Face. This means all Interests emitted by ndn-cxx will be nonce-less, unless explicitly added.
4. Do nothing, keeping the status quo of always generating a nonce during Interest encoding. This behavior is still compliant with the packet format spec.

I have a slight preference for (1a) or (4). I think (2) would be sub-optimal as it may cause an extra encoding for the same packet. (1b) and (3) would move the burden of nonce generation (and therefore packet re-encoding) to NFD for all packets created by ndn-cxx applications.

Irrespective of this decision, I think we should make sure NFD properly handles nonce-less Interests and add unit tests for this case if not already there.

My preference is (4). The intention of the spec change was to allow receiving nonce-less Interests and add nonce automatically, but this doesn't imply we should give NFD Interest without nonce from our library. Yes, NFD needs to ensure that nonce exists and add it when missing, but this should be more like an exceptional path, than a norm.

I also have a preference for (4) and agree we need to add a test case in NFD for receiving a packet with no nonce.