NFD

Why not maintain one RTT at the registered prefix level (not parent)? At least for now there should not be a scalability issue.

Why not maintain one RTT at the registered prefix level (not parent)? At least for now there should not be a scalability issue.

Per-prefix RTT estimators are maintained at parent of Data Name, not parent of Route prefix.

OK. Maybe at the registered prefix level would be good enough for most situations. But it doesn't hurt to do it at the parent of the data name level, as long as scalability is not an issue.

what if a prefix is multihomed to more than one gateway? say, /ndn/presentations content is available via Memphis and Arizona gateways. are you going to differentiate "external" and "internal" faces and only multicast among internal faces?

what if a prefix is multihomed to more than one gateway? say, /ndn/presentations content is available via Memphis and Arizona gateways. are you going to differentiate "external" and "internal" faces and only multicast among internal faces?

No.

This scenario violates the assumption used in this strategy: every nexthop connects to a laptop in one hop.

Therefore, the access router strategy is unsuitable for this namespace.

The access router strategy is intended to be practical for today's testbed operations, where each local site prefix sits on only one access router.

20141110 meeting with Beichuan approves the design.

We also recognize the limitation of this strategy that it cannot efficiently support multi-homed contents, and identify the need for another strategy to support that use case.

#2300 blocks this because it's needed by unit testing.

#2318 #2319 blocks this because it's needed by unit testing.

I've been thinking about the design of this very promising strategy proposal. Here are some questions which I hope are helpful for clarification.

As I understood the main problem is that the NCC strategy does not permit re-transmission to the same interface before the InterestLifetime is over.

1. Is the consumer re-transmission (which happens after an RTE timeout, right?) much faster/shorter than the InterestLifetime? Which are the expected durations for both? As asked in #2055 is it possible to reduce the InterestLifetime?

2. Is re-transmission on the same interface beneficial? In particular:

3. How likely is packet loss on the access link when considering that link-layer (WiFi) re-transmissions reduce local losses?

4. How likely is it that the next packet after a loss is successful? My guess would be that packet loss occurs in bursts and that the next Interest on this link is also likely to be lost (e.g., a laptop moving into bad WiFi reception)

5. Is sending to the same interface again more likely to return data than trying another one? If the FIB is correct, using another link may be better.

6. How do you intend to validate the performance of this strategy and show that it is indeed better than NCC in the mentioned scenario?

Sorry that this sounds much more critical than intended. Keep up the good work.

1. InterestLifetime SHOULD be set to the duration in which the Data is useful to the consumer. Consumer SHOULD NOT attempt to manipulate InterestLifetime in response to network conditions.
   Consumer MAY retransmit before InterestLifetime expires.
2. Yes. Retransmitting on the same face can recover from a possible packet loss.
3. On NDN testbed, the access link is a UDP tunnel over public Internet. Packet loss is non-negligible.
4. The next packet, aka the retransmitted packet, is typically at least an RTO apart. Thus, a burst of packet loss won't affect the retransmission.
5. Whenever the first choice doesn't work within RTO, all nexthops listed in the FIB entry will be used.
6. The strategy can be validated with NDN-RTC and other real applications.

InterestLifetime SHOULD be set to the duration in which the Data is useful to the consumer. Consumer SHOULD NOT attempt to manipulate InterestLifetime in response to network conditions.

Consumer MAY retransmit before InterestLifetime expires.

Thanks, I didn't know that. Can you tell me the reason for this? I guess the InterestLifetime is kept high to not discard packets that could possibly be useful for the consumer?

Seems like I am not the only one who makes the mistake of matching the InterestLifetime with RTO (http://onlinepresent.org/proceedings/vol2_2012/109.pdf http://www.lists.cs.ucla.edu/pipermail/ndnsim/2013-November/000964.html).
Maybe you want to document that somewhere.

The strategy can be validated with NDN-RTC and other real applications.

What about simulations? This question is a bit more general, but I am wondering how one can proof that a new strategy is worth the effort of higher complexity (following Occam's razor to prefer the simplest solution for a given problem).

Seems like I am not the only one who makes the mistake of matching the InterestLifetime with RTO (http://onlinepresent.org/proceedings/vol2_2012/109.pdf http://www.lists.cs.ucla.edu/pipermail/ndnsim/2013-November/000964.html).
Maybe you want to document that somewhere.

Agreed. This shall appear in ndn-cxx Application Developer Guide, but it's a separate Task.

What about simulations? This question is a bit more general, but I am wondering how one can proof that a new strategy is worth the effort of higher complexity (following Occam's razor to prefer the simplest solution for a given problem).

I don't want to block this Feature on ndnSIM. It could be separate Task.

I know that I'm kind of late, but I'm kind of against of having RTO/retransmission inside the strategy.

As I remember, the way to address link problems was to introduce a limited recovery inside the link (2.5) layer. This layer will do retransmissions much more efficiently and quicker than usually coarse RTO estimation (the initial value is 1 second). I would say, just allowing retransmitted interests to go through will be enough. Otherwise, there will be client-based retransmission, RTO retransmission, and interaction of both (I know the timer is cancelled, but there could be some interactions with previous hops).

This strategy is designed to solve the problems now, in a limited scenario as described in design slides.

I agree with the idea of link layer retx, but it won't come in v0.3.

Also, there is no RTO retx in this strategy.

1. forward to face X
2. RTO timeout
3. multicast to all nexthops except face X and the downstream

There is a form of RTO retx in this strategy. Given RTO timeout is not tied to Measurement entry lifetime, the following could happen:

• incoming interest
• found Measurement entry, forward to single next hop, set up RTO
• RTO expires, broadcast interest to all next hops
• ...
• incoming interest
• found Measurement entry, forward to single next hop, set up RTO
• RTO expires, broadcast interest to all next hops
• ...
• (repeat until Measurement entry is not found)

I'm not sure that multicast after RTO is useful... At least RTO should reset Measurement entry, so there is no delay in multicasting the interest next time.

I don't understand. Please be precise in your scenario, and include:

• Interest Name, Selectors, InterestLifetime
• list of faces (with FaceId), and their RTT
• what's stored in Measurements initially
• time (milliseconds from scenario starts) of each event
• incoming FaceId of each packet

After you provide these information, I'll determine whether there's a problem.

I've added Ovehead test case to show my concern about the strategy.

I've seen the Overhead test case added in commit 2c1243ada4b8199e9c3357c8b71836b3e82a749f.
The strategy's behavior may be inoptimal in this scenario, but it's still correct.
Changing the design may cause inoptimal behavior in other scenarios.
This problem should be addressed in a separate issue.

The strategy is implemented using a design approved in note-9.
If there's no other problem, the code should be approved, and that test case will be deleted before merging but readded in the future issue.
I disagree without changing the design again in this issue.
I want to let the current design out for a real-world test.

The design concern mentioned in note-26~29,31~32 is split to #2403.

The intention of my comments is to raise awareness of the issues. I'm not asking for design changes as part of this task.

A brief description of the new strategy is added to NFD Developer Guide.