Project

General

Profile

Actions

Bug #3981

closed

ndncatchunks: wrong Nack handling in DiscoverVersionIterative

Added by Junxiao Shi over 7 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Start date:
Due date:
% Done:

0%

Estimated time:
3.00 h

Description

Steps to reproduce:

  1. nfd-start
  2. ndnputchunks -v -f 20000 /demo/NFD/city-hash.cpp < ./NFD/core/city-hash.cpp
  3. ndncatchunks -v /demo/NFD/city-hash.cpp, retrieval succeeds
  4. kill the process in step2
  5. ndncatchunks -v /demo/NFD/city-hash.cpp (within 20 seconds of step3)

Expected: step5 retrieval succeeds, because Data is in ContentStore and not stale
Actual: ERROR: Could not retrieve data for /demo/NFD/city-hash.cpp, reason: NoRoute
If we prevent Nack-NoRoute by setting best-route v1 strategy, step5 retrieval succeeds as expected.

Actions #1

Updated by Junxiao Shi over 7 years ago

  • Tracker changed from Feature to Bug
  • Assignee set to Shuo Yang

Reported by Marzieh Babaeianjelodar http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2017-February/001562.html.

Assigned to Shuo Yang who is the current maintainer of ndncatchunks. The original authors of I88e4fc1a8e33a0d61a95e2291cccc7b998647489, Steve and Andrea, are inactive recently.

Actions #2

Updated by Shuo Yang over 7 years ago

I doubt whether or not it is a bug?

The point of using iterative version discovery is to discover the latest version from the producer. (see: https://github.com/named-data/ndn-tools/tree/master/tools/chunks#version-discovery-methods-in-ndncatchunks). It's implemented with the following logic(https://github.com/named-data/ndn-tools/blob/master/tools/chunks/catchunks/discover-version-iterative.cpp):

  1. consumer express an Interest, and it hits the content store (assuming producer has died).
  2. consumer express the same Interest again (excluding the first one), this Interest gets no route to go since the producer has died.

I think seeing NACK in this case is what it is supposed to be. If a user just wants to retrieve the content without worrying about the latest version, he can use fixed version discovery instead. I've tested the above 5 steps with fixed version discovery, and it works fine.

Actions #3

Updated by Junxiao Shi over 7 years ago

This is a bug. A network Nack should never result in a worse outcome than a timeout.

Copying Beichuan's argument.

A consumer never knows whether its request will hits the producer or not. Thus the so-called “latest” version is the latest version that is available from the network, not necessarily from the producer. When the producer is not available, the discovery should return the latest version it can find, in this case, the version in the CS. While NACK-NoRoute is fine, the consumer should treat this NACK the same way as it treats a timeout, and concludes that the last version it got is the latest version it can find.

Actions #4

Updated by Shuo Yang over 7 years ago

  • % Done changed from 0 to 80
Actions #6

Updated by Davide Pesavento over 7 years ago

  • Status changed from New to In Progress
Actions #7

Updated by Junxiao Shi over 7 years ago

  • Assignee changed from Shuo Yang to Anonymous
Actions #8

Updated by Davide Pesavento about 7 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 80 to 0

Shuo Yang wrote:

Code review url: https://gerrit.named-data.net/#/c/3778/

This change has been abandoned so I'm moving the status to "Feedback" (it should be "New" but redmine doesn't let me).

Actions #9

Updated by Junxiao Shi about 7 years ago

  • Status changed from Feedback to New
Actions #10

Updated by Anonymous about 7 years ago

  • Priority changed from Normal to Low
Actions #11

Updated by Davide Pesavento about 7 years ago

  • Subject changed from chunks: wrong Nack handling in DiscoverVersionIterative to ndncatchunks: wrong Nack handling in DiscoverVersionIterative
Actions #12

Updated by Anonymous almost 7 years ago

  • Assignee deleted (Anonymous)
Actions #13

Updated by Davide Pesavento over 5 years ago

  • Status changed from New to Rejected

DiscoverVersionIterative has been removed in #4556

Actions

Also available in: Atom PDF