Task #2007
closed
LocalControlHeader: Express Interest without forwarding
0%
Description
Design a LocalControlHeader-based protocol to allow a local application to express an Interest without forwarding.
Upon receiving such an Interest, forwarder should:
- lookup ContentStore, and return Data if there's a match
- keep the Interest in PIT, but do not forward it
- if there's incoming Data matching this PIT entry, such Data is delivered to the requester
This is useful in a multi-access group, where application wants to delay its own response so that it won't duplicate a response from another participant.
This is especially important when bandwidth or energy of transmission is a scarce resource.
Updated by Junxiao Shi about 10 years ago
- Subject changed from Express Interest without forwarding to LocalControlHeader: Express Interest without forwarding
This can be realized by setting ClientControlStrategy and then specify nexthop=NullFace.
But I'm unsure whether the namespace would need some other strategy; but #2000 would allow composable strategy.
I'm also unsure whether it's application's responsibility to avoid duplicate responses from multiple participants, or should some forwarder component do this.
Updated by Lan Wang about 10 years ago
For the scenario you have -- delaying application's response, it can be easily done at the application. What's described here doesn't seem to actually do the delaying and then sending after the delay.
Maybe related to this task -- it would be desirable to allow NLSR nodes to sniff Data packets of a specific prefix. An NLSR process just needs to specify a name prefix. Whenever any Data packet matching the name prefix is received on the multicast link (could be a response to another NLSR process' Interest), it will be delivered to the NLSR process (without this process explicitly expressing the Interest). Is this already implemented?
Updated by Junxiao Shi about 10 years ago
I had the idea of a sniffing feature (filtering on face, direction, type of packet, and Name prefix) before, but @Jeff thinks it's better to do it in "NDN-way" which means the application should express an Interest for each packet.
Updated by Davide Pesavento about 10 years ago
Junxiao Shi wrote:
@Jeff thinks it's better to do it in "NDN-way" which means the application should express an Interest for each packet.
A packet sniffer is supposed to be passive. If it starts sending interests, it may modify the state of the network.
Updated by Junxiao Shi about 10 years ago
I agree that packet sniffer should be passive and shouldn't express Interests, even if those Interest are not forwarded.
This Task is about regular applications who wants to receive passing Data but does not want to transmit Interest.
It's similar to Scope=0 and namespace-base scope control won't help in this case.
Updated by Jeff Burke about 10 years ago
I agree with the proposal here. As Junxiao mentions, this is different than a packet sniffer function - it is for applications that wish to listen for but not solicit data from the network. My understanding is that an application would make an API call to enable this LocalControlHeader feature, than just add the header to subsequent Interests that would suppress forwarding of the Interest beyond the local NFD.
Updated by Junxiao Shi about 10 years ago
I'm unsure about whether this feature deserves a new field in LocalControlHeader.
The alternative is: setting NextHopFaceId=FACE_NULL(255) to tell the strategy not to forward the Interest.
Updated by Alex Afanasyev about 10 years ago
With FACE_NULL, it would be necessary to use client control strategy for this namespace. I feel this is too harsh restriction.
Updated by Junxiao Shi about 10 years ago
With #2000, strategies are composable.
Just add a building block in front of all strategies that says "if NextHopFaceId is FACE_NULL, then don't forward".
Updated by Junxiao Shi almost 8 years ago
- Status changed from New to Resolved
- Target version set to v0.6
With
FACE_NULL, it would be necessary to use client control strategy for this namespace. I feel this is too harsh restriction.
Since #3783, client control strategy is no longer required. Thus, setting NDNLPv2 NextHopFaceId=FACE_NULL fulfills the original requirement.
Updated by Junxiao Shi almost 8 years ago
- Status changed from Resolved to Closed
At 20170206 call Lan confirms the solution of NextHopFaceId=FACE_NULL is acceptable.