NFD

With the version of NFD currently deployed on the testbed (0.6.6), LpReliability makes use of nfd::RttEstimator, which has a minimum RTO of 1ms. As of 0.7.0, LpReliability relies upon ndn::util::RttEstimator from ndn-cxx to compute its estimated RTOs, which features the minimum RTO of 200ms expected in the issue description. Therefore, the scenario described in the issue description seems to be the expected behavior in 0.6.6.

Ok, that explains the aggressive retransmissions, but why are we seeing multiple Data/Nacks for the same Interest in some cases?

Davide Pesavento wrote:

Ok, that explains the aggressive retransmissions, but why are we seeing multiple Data/Nacks for the same Interest in some cases?

I'm assuming that you're referring to a Data packet and Nack for the same Interest like seen at lines 480-481 and 483 in the attached pcap file, all in response to the Interests at lines 478-479? If so, it looks like the two Data packets being sent are the first transmission and then a retransmission of the same Data after the first one timed out. Both are being sent in response to the original Interest. Then, the Nack occurs because the Interest was retransmitted, despite the first copy having being received successfully, causing a duplicate Interest packet to be processed with the same nonce, causing a Duplicate Nack to be sent in response. The remaining string of Nacks/Datas for the same Interest are probably caused by retransmission semantics due to the use of the older nfd::RttEstimator with the lower minimum RTO - my educated guess is that the low RTOs are causing the relevant packets to be dropped from the retransmission queue with that TxSequence before they can be acknowledged (with those Acks likely being dropped since they refer to now unknown TxSequences), causing further retransmissions.

Eric Newberry wrote:

Then, the Nack occurs because the Interest was retransmitted, despite the first copy having being received successfully, causing a duplicate Interest packet to be processed with the same nonce, causing a Duplicate Nack to be sent in response.

But the Nack is generated by higher layers, which means LpReliability is passing all the retransmitted Interests up to the forwarder/strategy. Is that the expected behavior? I believe LpReliability should be transparent and not cause additional network-layer packets to be seen by the upper layers. In other words, retransmissions should be filtered and dropped.

Davide Pesavento wrote:

Eric Newberry wrote:

Then, the Nack occurs because the Interest was retransmitted, despite the first copy having being received successfully, causing a duplicate Interest packet to be processed with the same nonce, causing a Duplicate Nack to be sent in response.

But the Nack is generated by higher layers, which means LpReliability is passing all the retransmitted Interests up to the forwarder/strategy. Is that the expected behavior? I believe LpReliability should be transparent and not cause additional network-layer packets to be seen by the upper layers. In other words, retransmissions should be filtered and dropped.

Yes, this is seemingly the expected behavior, since LpReliability has no understanding of upper layer semantics (apart from reporting lost Interests to the strategy). I'll look further into the design to see if there was any discussion of this issue around the time of initial implementation.

Eric Newberry wrote:

Davide Pesavento wrote:

Eric Newberry wrote:

Then, the Nack occurs because the Interest was retransmitted, despite the first copy having being received successfully, causing a duplicate Interest packet to be processed with the same nonce, causing a Duplicate Nack to be sent in response.

But the Nack is generated by higher layers, which means LpReliability is passing all the retransmitted Interests up to the forwarder/strategy. Is that the expected behavior? I believe LpReliability should be transparent and not cause additional network-layer packets to be seen by the upper layers. In other words, retransmissions should be filtered and dropped.

Yes, this is seemingly the expected behavior, since LpReliability has no understanding of upper layer semantics (apart from reporting lost Interests to the strategy). I'll look further into the design to see if there was any discussion of this issue around the time of initial implementation.

I looked at the original design document (https://docs.google.com/presentation/d/1cP1ya0oEUw1wjpF3SWqaUgLNLx5iH50Y7v2slVTvLOU) and it appears that deduplicating retransmissions was not considered in the design of this protocol.

Eric Newberry wrote:

Yes, this is seemingly the expected behavior, since LpReliability has no understanding of upper layer semantics (apart from reporting lost Interests to the strategy).

You don't need to understand upper layer semantics. A simple "packet identifier" that is kept the same for all LP-layer retransmissions should be sufficient.

Davide Pesavento wrote:

Eric Newberry wrote:

Yes, this is seemingly the expected behavior, since LpReliability has no understanding of upper layer semantics (apart from reporting lost Interests to the strategy).

You don't need to understand upper layer semantics. A simple "packet identifier" that is kept the same for all LP-layer retransmissions should be sufficient.

You're right. This already exists as the Sequence field, although it is currently only included in packets that are fragmented, presumably to reduce the size of transmitted frames. I think we could use this to detect duplicates if we also included it when LpReliability is enabled on the link.

Per the NFD call on February 6, 2020, the following changes to the reliability protocol will be adopted to resolve the problems described in this issue:

• The Sequence field is now required to be included in transmitted LpPackets when the LpReliability feature is enabled.
• Received LpPackets will have their fragments dropped if their Sequence field matches the Sequence of an already received LpPacket on a link.
• To enable the above, the receiver will keep track of received Sequence numbers for 1x the estimated link RTO at the time of receipt.

These changes are reflected in NDNLPv2 revision 57.