NFD

20140220 conference call decides:

• Duplicate suppression applies to Data packets only, because delaying Interests causes too much end-to-end delay.
• Duplicate suppression with random delay will cause packet reorder. Congestion control scheme should not expect in-order delivery.

1/ I think this can be postponed until after the first release... it's just an optimization anyway.

2/ Duplicate suppression applies to multicast Ethernet faces too, so it should be factored out in a common implementation, if possible.

Some notes after reviewing the slides and my own implementation of data cache reply suppression.

• We found that data reply suppression can be accomplished solely in a forwarding strategy. However, a switch seems like it would require a naming schema.
• Link conditions for data reply suppression could also be tracked within the forwarding strategy via measurements table.
• Multicast/Unicast switch guaranties a single data reply. Data reply suppression does not.
  
• More than one reply may be beneficial in high loss link conditions.
• Our data cache suppression works on content store hits. Therefore it works for upstream NFD's that have the data cached but are not the original data providers.
• In response to "all upstreams must still producer/fetch the Data in response to every Interest, although all but one upstream's work will be wasted." for a multicast/unicast switch there is an additional network overhead of responding to the initial interest where in data reply suppression the overhead is a randomized delay. If link conditions can be monitored the data reply suppression delay could result in less overall delay than two rounds of interests being sent.
• Could a multicast/unicast switch be implemented at an application library level? This would avoid altering NFD code base.

2020-04-09 NFD call discussed this issue.

Davide claims that you cannot suppress both Interest and Data due to hidden terminal problem.
In the topology below, A and B can hear each other, and B,C,D can hear each other.

1. Both A and C send an Interest. B hears both Interests.
2. D replies with Data. B hears the Data.
3. If B suppresses Data forwarding, A would not be able to retrieve the Data.

A    B    C
          D

Lan explains that Alvy has a solution to the hidden terminal problem: suppression probability.
By tuning the probability, it is possible to adjust how many duplicates you get, without breaking communication above.

Lixia suggests that we can start with one-hop WiFi ad hoc scenario.
However, it is unclear who is using NDN WiFi ad hoc, other than in simulations and completely fabricated research scenarios. In particular, Android does not support WiFi ad hoc at all.
Lan mentions vehicular use case (DSRC), but Davide believes it's no longer relevant in industry.
Lixia believes that industry's ignorance on ad hoc is because the lack of mature solution.

Alex mentions WiFi mesh that use peer-to-peer communication.
It allows WiFi to have mostly point-to-point communication without access point, but the protocols support multicast as well.
Davide explains that it uses HWMP protocol to establish a routing table, but this solution can only work with mostly static network and will break down if there's too-fast mobility.

Alex also mentions sensor networks including Zigbee that are fundamentally ad hoc.
No further discussion occurred on this scenario.

It's still being debated whether this feature is part of face or part of forwarding/strategy.
Lixia insists that this feature should belong in the face, because this is a L2 feature and suppression should occur per face.
Both Alvy and Alex have experimental implementation that have this feature in the strategy, because the strategy is already remembering relevant information in the tables.
No agreement was reached in this point.

Junxiao Shi wrote:

Davide claims that you cannot suppress both Interest and Data due to hidden terminal problem.

It's actually worse than that. The scenario in the example breaks down even if you only have Data transmission suppression. And you have a similar problem with only Interest suppression.
(also note that "hidden terminal" is a term I made up, it is not related to the hidden terminal problem in 802.11)

Lan explains that Alvy has a solution to the hidden terminal problem: suppression probability.
By tuning the probability, it is possible to adjust how many duplicates you get, without breaking communication above.

Yes but I'm not sure if I'd call that a "solution", it's not clear to me how to effectively set this probability. If it's too low, some nodes may need several retransmissions before obtaining the content; if it's too high, then you still have a large number of duplicate Data packets in the network.
Maybe Data suppression should be disabled (or probability of suppressing should be greatly reduced) if a node receives the same Interest more than once in a short period of time?