NFD » ndn-cxx

So far NDN-JS has an async signing API, which is necessary to use crypto.subtle.

In ndn-cxx,

• There isn't an equivalent of crypto.subtle that requires async API.
• One context switch (or worse, thread creation) for every signing is too expensive.
• Merely deferring signing using io.poll brings little benefit, and would require using io_service in more places.

Junxiao Shi wrote:

• There isn't an equivalent of crypto.subtle that requires async API.

The requirement for an async API comes from above, not below. IOW we want to be able to sign stuff in an async manner from the main NFD thread without blocking unrelated forwarding operations. If ndn-cxx is not the proper place to implement this, we can do it in NFD.

• One context switch (or worse, thread creation) for every signing is too expensive.

This has to be measured, but as far as I understand the OSX TPM is extremely slow.

• Merely deferring signing using io.poll brings little benefit, and would require using io_service in more places.

Why is more usage of io_service a problem?

This has to be measured, but as far as I understand the OSX TPM is extremely slow.

Yes, but only key-signing keys are stored in OSX TPM. When an app starts, a short-lived data-signing key is created and signed using key-signing key.

The data-signing key is stored in memory, and signing using data-signing key is fast.
(see #1204 for more details and challenges in this design)

The fundamental question is: what's the benefit to have async signing API?

Is actual signing done in same thread, or in a different thread?

If it's in same thread, what performance benefit can this bring?

If it's in a different thread, justify the complexity of managing a separate thread, and the overhead of context switching (compared to synchronous signing with in-memory data-signing key).

If the signing speed is the only reason, I think we should go with short-lived key solution, rather than making an async api. Even if multi-thread is available, application may have separate threads for signing, which does not necessarily require an async API.

Signing speed is not the only reason. Signing operation (when considering real TPM) is by itself an asynchronous and on OSX it is already a separate thread (ok ok, it is really slow on OSX anyways).

What is proposed is to bring an option for the naturally asynchronous operation an asynchronous interface. In some cases (management in NFD) it would allow completely remove heavy processing inside forwarding path (even 1ms can be bad there).

The proposal is not to eliminate synchronous operation, rather provide an alternative option that can be used in some applications.

In NFD Management, we could move most processing into a separate thread (boundary at ManagementDispatcher), including everything from verification to signing, then use io.dispatch to affect tables or faces. This is better than solely moving out signing, because verification and encryption are slow as well.

Please answer first two questions in note-3.

Junxiao Shi wrote:

In NFD Management, we could move most processing into a separate thread (boundary at ManagementDispatcher), including everything from verification to signing, then use io.dispatch to affect tables or faces. This is better than solely moving out signing, because verification and encryption are slow as well.

Yep, this could be done as well, I dunno how complicated it would be though as I'm not familiar with that part of NFD.

If we are using the real tpm, signing is usually done by a separate process.

At 20150803 conference call, Alex reveals the motivation of this Feature is #1589.