Project

General

Profile

Feature #4228

Face: send Nack after every InterestCallback has responded

Added by Junxiao Shi about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Base
Target version:
Start date:
08/07/2017
Due date:
% Done:

100%

Estimated time:
6.00 h

Description

Currently, if a client Face dispatches an incoming Interest to multiple InterestCallbacks, as soon as one InterestCallback responds with a Nack, the Nack is returned to NFD. At this time, it is possible for Data to be available through another InterestCallback.
Thus, the face should wait for all InterestCallbacks to respond with a Nack before sending the Nack to NFD.

The combined Nack shall have the least severe reason, similar to NFD's multicast strategy.
Given Face::put(lp::Nack) API does not indicate which InterestCallback is sending the Nack, the face needs to wait for the same number of Nacks as the number of InterestFilters matching the Interest.

Note that this behavior applies to Nack only. If any InterestCallback responds with a Data, the Data can be delivered right away.


Related issues

Blocks ndn-cxx - Feature #3979: Configure Face::expressInterest to allow forward Interest to the incoming faceClosedJunxiao Shi02/26/2017

Actions
#1

Updated by Junxiao Shi about 3 years ago

  • Blocks Feature #3979: Configure Face::expressInterest to allow forward Interest to the incoming face added
#2

Updated by Junxiao Shi about 3 years ago

This feature requires an extension of Face::Impl::PendingInterestTable.
Interests coming from NFD shall be added to this table, together with Interest expressed through Face::expressInterest API.
Each record has a counter, which represents the number of InterestCallbacks receiving the Interest minus the number of Face::put(lp::Nack) against the Interest. In #3979, this counter is also incremented when the Interest is sent toward NFD, and decremented when a Nack against the Interest is coming from NFD.

#3

Updated by Junxiao Shi about 3 years ago

  • Status changed from New to In Progress
  • Assignee set to Junxiao Shi

I'm starting the Face::Impl::PendingInterestTable extension in https://gerrit.named-data.net/4097 patchset1.
I notice a problem:

In #3678, thread-safe Face frontend class encodes Data and Nack into wire format, and passes the wire encoding to single-threaded Face::Impl backend class which then sends the packet to NFD via a Transport.
If I need to find the pending Interest record that is satisfied by Data or rejected by Nack, I cannot do so in Face frontend class because it must be thread-safe. Instead, I'll have to pass Data and Nack to Face::Impl backend class, but that requires copying the Data or Nack, which leads to performance concerns.

Note that finding the pending Interest record is not only required by this issue, but also needed by #3979. In #3979, a Data passed to Face::put needs to be matched against pending Interest records to see which pending Interests received via Face::expressInterest could be satisfied.

#4

Updated by Junxiao Shi about 3 years ago

  • % Done changed from 0 to 10

Alex agreed with copying packet to Impl at 20170809 NFD call.

https://gerrit.named-data.net/4100 moves packet encoding to Impl class.
There is a small behavior change: if packet size exceeds limit, Face::expressInterest and Face::put may not throw exception; exception may be thrown by Face::processEvents when encoding happens.
Previously, Face::expressInterest has a packet size check on the bare Interest without NDNLP headers, but this check is unreliable because NFD side requires the whole LpPacket to stay within the limit.

#5

Updated by Junxiao Shi almost 3 years ago

  • % Done changed from 10 to 40

https://gerrit.named-data.net/4097 patchset3 inserts pending Interest records for Interests received from the forwarder, and queries those records when the app puts a Data or Nack to the face.

In Face::Impl::putData, the querying currently can yield one of two results: either the Data matches a pending Interest from the forwarder, or there is no match. The Data goes to the forwarder in both cases, because the library should support sending unsolicited Data and allow the forwarder's policy to decide whether to reject them.
In #3979, this querying may also find the Data matching an Interest from the local app, and in that case the Data would not go to the forwarder (actually, this is already possible, but Face::Impl::putData is unlikely to be invoked if Interest was not sent to a callback in the local app).

In Face::Impl::putNack, the Nack goes to the forwarder only if it matches a pending Interest record from the forwarder. This means, it is no longer possible to transmit an unsolicited Nack.
In a later commit of this issue, this procedure will be extended to send a Nack only if all callbacks receiving the Interest has nacked.

#6

Updated by Junxiao Shi almost 3 years ago

  • % Done changed from 40 to 60
#7

Updated by Junxiao Shi almost 3 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 60 to 100
#8

Updated by Junxiao Shi almost 3 years ago

The last change is causing a NFD build failure http://jenkins.named-data.net/job/NFD/5735/OS=Ubuntu-16.04-32bit/console.
This is fixed on NFD side in https://gerrit.named-data.net/4175.

#9

Updated by Junxiao Shi almost 3 years ago

This is fixed on NFD side in https://gerrit.named-data.net/4175.

There is still a memory error over there, and the problem comes from ndn-cxx.
https://gerrit.named-data.net/4178 has the fix.

#10

Updated by Davide Pesavento almost 3 years ago

Anything else to do here?

#11

Updated by Junxiao Shi almost 3 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF