[Nfd-dev] Interest equality for for Nack

[Klaus Schneider]

Hi Junxiao,

>> The Nack must also carry the latest Nonce coming from the downstream.
>> Otherwise, in case a Nack and a retransmitted Interest are in-flight at
>> the same time between an upstream and a downstream, if the downstream
>> ignores the Nonce and accepts the Nack, it would incorrectly conclude
>> that the upstream cannot answer its retransmitted Interest while the
>> upstream is actively trying to find content for its retransmitted Interest.

- Is there any specification of this design decision?

- Is the "retransmitted Interest" created by the link layer (NDNLP) or 
by the NDN network layer?

I guess that the downstream router retransmits a packet because it 
thinks that the upstream has lost the packet. Shouldn't this 
retransmission timer be much longer than it usually takes for the 
upstream to send a NACK back? Thus, the retransmitted Interest and the 
NACK are unlikely to be in-flight at the same time.

You send an interest to the upstream and either get a NACK back quickly, 
or not at all.

Moreover, whatever the reason for the original NACK was (let's say "no 
path"), there is a good chance that the condition will still apply for 
the re-transmitted interest, so the downstream would make no mistake in 
accepting the NACK for the old packet. (If necessary, I'll continue the 
discussion on the other two types of NACKs).

I'm not saying that "putting the latest nonce from downstream interest 
into NACK packets" is a bad choice. It might just be unnecessary for 
most cases.


Best regards,
Klaus




On 04/25/2016 04:40 PM, Junxiao Shi wrote:
> Hi Jeff
>
> Nack is hop-to-hop. A Nack packet cannot be "forwarded".
> When NFD decides to send a Nack to a downstream, the Nack being sent is
> constructed from the latest Interest received from the downstream; it's
> not a copy of a Nack received from elsewhere. Thus, it would have the
> same wire encoding.
>
>  From protocol point of view, the Nack must be able to locate the
> correct PIT entry, which requires it to have the same Name, Selectors,
> and Link as the original Interest.
> The Nack must also carry the latest Nonce coming from the downstream.
> Otherwise, in case a Nack and a retransmitted Interest are in-flight at
> the same time between an upstream and a downstream, if the downstream
> ignores the Nonce and accepts the Nack, it would incorrectly conclude
> that the upstream cannot answer its retransmitted Interest while the
> upstream is actively trying to find content for its retransmitted Interest.
>
> After fixing Name, Selectors, Link, and Nonce, the only leftover field
> is InterestLifetime. Theoretically, the protocol could operate correctly
> even if the InterestLifetime in Nack differs from the InterestLifetime
> in Interest. In NFD implementation, InterestLifetime field never
> changes, so it's safe for ndn-cxx to compare the wire encoding of entire
> Interest.
>
> Yours, Junxiao
>
> On Mon, Apr 25, 2016 at 12:13 PM, Thompson, Jeff <jefft0 at remap.ucla.edu
> <mailto:jefft0 at remap.ucla.edu>> wrote:
>
>     Hello all,
>
>     To support the network Nack in ndn-cxx, expressInterest takes a
>     NackCallback and stores this along with the Interest in the library
>     PIT. When ndn-cxx receives a Nack, it has to find the PIT entry with
>     the “same” interest as the interest in the Nack packet. The test for
>     “same” uses exact equality of the Interest wire encoding (including
>     the nonce and all the selectors).
>     https://github.com/named-data/ndn-cxx/blob/4b4699897cf281c08b85343a1b0d02961eb727f0/src/interest.hpp#L429
>
>     Is it guaranteed that the Interest which goes through the whole
>     network and is returned Nack will have the exact same encoding bytes
>     as the Interest that was originally expressed? Is this stated
>     somewhere? Could the encoding ever be different?
>
>     Thanks,
>     - Jeff T
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>