Bug #3335
closed
ping: does not process Nack
Added by Junxiao Shi over 8 years ago. Updated almost 8 years ago.
100%
Description
ndn::ping::client::Ping::performPing is using a deprecated overload of Face::expressInterest that does not process Nack.
To fix this bug, Nack processing should be added.
Updated by Junxiao Shi over 8 years ago
- Blocks Task #3334: Deprecate Face::expressInterest non-Nack overloads added
Updated by Junxiao Shi over 8 years ago
- Tracker changed from Task to Bug
- Description updated (diff)
Updated by Teng Liang about 8 years ago
On receiving NACK, what messages are expected to be printed out? Sequence number and NACK reason?
Updated by Junxiao Shi about 8 years ago
Answer to note-4:
Currently, Data and timeout prints:
content from /ndn/edu/arizona: seq=4968989894049509434 time=137.026 ms
timeout from /ndn/edu/arizona: seq=4797694481388730425
I think Nack can print in a similar format:
nack from /ndn/edu/arizona: seq=10327383310863275811 time=112.471 ms reason=Congestion
Updated by Junxiao Shi about 8 years ago
A related question is:
How Nack should be reflected in the statistics?
So far, the statistics is following the format of IP ping, but there's no Nack in IP ping that we can learn from.
I don't have a good answer for this.
Updated by Teng Liang about 8 years ago
Junxiao Shi wrote:
A related question is:
How Nack should be reflected in the statistics?So far, the statistics is following the format of IP ping, but there's no Nack in IP ping that we can learn from.
I don't have a good answer for this.
As Nack is not the expected packet and can be generated by any router along the path, it should be considered as a packet loss.
Updated by Junxiao Shi about 8 years ago
I agree with note-7. This also implies that the RTT of Nacks should not be included in the overall RTT in the statistics.
Updated by Anonymous about 8 years ago
Maybe you can have a separate count for the nacks, like:
7 packets transmitted, 5 received, 2 nacked, x% packet loss, y% nacked, time 12.5148 ms
Maybe you could also keep separate RTT estimates for NACKs to give the user some idea where the nacks come from:
rtt min/avg/max/mdev = 1.42586/2.50295/6.29782/1.89921 ms
nack min/avg/max/mdev = 1.25688/3.69249/10.555/3.96418 ms
Updated by Junxiao Shi about 8 years ago
I agree with the first half of note-9: having counts for Nacks.
I disagree with the second half of note-9.
Nack is only on a single hop.
A forwarder may receive a Nack and transmit another Nack, but never forward a Nack.
Thus, the origin of any Nack received by application is the directly connected forwarder.
Updated by
Updated by Anonymous about 8 years ago
Junxiao Shi wrote:
I agree with the first half of note-9: having counts for Nacks.I disagree with the second half of note-9.
Nack is only on a single hop.
A forwarder may receive a Nack and transmit another Nack, but never forward a Nack.
Thus, the origin of any Nack received by application is the directly connected forwarder.
Agreed, makes sense!
Updated by Junxiao Shi almost 8 years ago
- Status changed from Code review to Closed
- % Done changed from 0 to 100
Updated by Junxiao Shi almost 8 years ago
- Related to Bug #3694: integ fails due to ndnpeek/ndnping syntax change added