Bug #4983
closed
AsfStrategy only records the first response when it forwards a packet and sends a probes to an alternate face
100%
Description
When Asf Strategy forwards an interest it may also send a probe interest to an alternate face to get additional metrics. However, when the data response comes back it consumes the PIT entry so only the quickest response is recorded. The probe is generally wasted work as the slower response comes back as unsolicited data. There is no pipeline to the forwarding strategy for when unsolicited data is received. Additionally even if we added a trigger for this, the rtt calculation requires the PIT entry.
If the strategy was able to record more than one metric during probing rounds then it could respond quicker during congestion or primary link failure.
This seems like a bug but if the implementation was the original intention then I suppose this is a new feature for Asf.
Updated by Ernest McCracken about 5 years ago
Here is an example from the logs. Removed unrelated log entries.
1565972579.955383 DEBUG: [nfd.Forwarder] onIncomingInterest face=277 interest=/A/%FE%05
1565972579.955429 TRACE: [nfd.AsfStrategy] Looking for best face for /A
1565972579.955459 TRACE: [nfd.AsfStrategy] Forwarding interest to face: 260
1565972579.955464 DEBUG: [nfd.Forwarder] onOutgoingInterest face=260 interest=/A/%FE%05
1565972579.955503 TRACE: [nfd.AsfStrategy] Scheduling timeout for /A FaceId: 260 in 41 milliseconds ms
1565972579.955529 TRACE: [nfd.AsfStrategy] Sending probe for /A/%FE%05?ndn.MaxSuffixComponents=1&ndn.InterestLifetime=500&ndn.Nonce=11045153051104515305 to FaceId: 263
1565972579.955534 DEBUG: [nfd.Forwarder] onOutgoingInterest face=263 interest=/A/%FE%05
1565972579.955583 TRACE: [nfd.AsfStrategy] Scheduling timeout for /A FaceId: 263 in 1000 milliseconds ms
1565972579.958895 DEBUG: [nfd.Forwarder] onIncomingData face=260 data=/A/%FE%05
1565972579.958928 DEBUG: [nfd.Forwarder] onIncomingData matching=/A/%FE%05
1565972579.958947 DEBUG: [nfd.Strategy] afterReceiveData pitEntry=/A/%FE%05 inFace=260 data=/A/%FE%05
1565972579.958984 DEBUG: [nfd.Forwarder] onOutgoingData face=277 data=/A/%FE%05
1565972579.959029 DEBUG: [nfd.Forwarder] onInterestFinalize interest=/A/%FE%05 satisfied
1565972579.959464 DEBUG: [nfd.Forwarder] onIncomingData face=263 data=/A/%FE%05
1565972579.959473 DEBUG: [nfd.ContentStore] insert /A/%FE%05
1565972579.959519 DEBUG: [nfd.Forwarder] onDataUnsolicited face=263 data=/A/%FE%05 decision=cache
Updated by Junxiao Shi about 5 years ago
This is most likely a regression when "straggler timer" feature was dropped. The correct solution under current API is: when a PIT entry is satisfied, if ASF has transmitted a probe and wants to wait for the response, it needs to explicitly request an extension of PIT entry lifetime.
Updated by Davide Pesavento about 5 years ago
- Subject changed from Asf Strategy only records the first response when it forwards a packet and sends a probes to an alternate face. to AsfStrategy only records the first response when it forwards a packet and sends a probes to an alternate face
- Start date deleted (
08/20/2019)
Updated by Ernest McCracken about 5 years ago
Is there a way to extend a scheduled event without canceling it and rescheduling? I see in the forwarder setExpiryTimer it calls cancel on the pit entry's eventid then schedules onInterestFinalize. While we have access to the pit entry in the strategy, onInterestFinalize is private in the forwarder.
Updated by Junxiao Shi about 5 years ago
Strategy should invoke this->setExpiryTimer(pitEntry, duration) to prolong PIT entry lifetime. See notes on beforeSatisfyInterest and afterReceiveData and afterReceiveNack.
Strategy should not worry about how setExpiryTimer is internally implemented.
Updated by Ernest McCracken about 5 years ago
Ok thanks. That fix did work. The question now is what is an appropriate duration and when to invoke setExpiry (only when a probe is active). I don't believe there is currently anything in the namespace info to denote that a probe is active though initially this doesn't seem like a complex thing to track.
Updated by Junxiao Shi about 5 years ago
I don't believe there is currently anything in the namespace info to denote that a probe is active
It's strategy's responsibility to know whether it's waiting for a probe on a PIT entry. It may store this information on PIT out record.
In some cases, the presence of PIT out record would be sufficient to determine.
Updated by Davide Pesavento over 4 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100