[Ndn-interest] NACK

[Klaus Schneider]

I think there are at least two cases in which the verification fails: 1) 
random errors which couldn't be corrected by a lower layer and 2) 
purposeful manipulation of the packet by a malicious attacker.

I don't know how easy these are to distinguish, but in both cases it's 
likely that the in-network routers have to solve the problem by 
forwarding interests on a different path.

There is a trade-off in how persistently routers should retransmit 
before notifying the consumer: In one extreme all routers on the path 
try all of their paths before sending a NACK back (potentially 
increasing the delay to the point where the consumer no longer needs the 
data). In the other extreme, the NACK goes directly to the consumer and 
then the consumer sends a retransmission to tell the routers to try a 
different path (increasing delay and packet overhead compared to routers 
retransmitting on their own).

It is also useful to identify how fine-granular the problem is: Did the 
data corruption affect 1) just a single packet, 2) many/most packets 
under that FIB-prefix-face combination, or 3) all packets send over that 
face?

This information can then be used to make better decisions at the 
forwarding layer, like moving traffic of the affected "flow"/FIB 
prefix/face. I think the problem is quite similar to the one of congestion.

Best regards,
Klaus






On 30.06.2016 14:29, Cesar Ghali wrote:
> I just want to highlight that interest NACKs that Lixia mentioned are
> studied as two types of NACK messages in the paper that Gene shared earlier:
> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7288477
>
> Cesar
>
>
> On Wednesday, June 29, 2016, Lixia Zhang <lixia at cs.ucla.edu
> <mailto:lixia at cs.ucla.edu>> wrote:
>
>     one detail that I have not seen mentioned so far: interest NACK
>     versus data packet NACK.
>
>     It seems to me that interest NACK is relatively well understood: a
>     forwarding node failed to forward a received interest hence
>     generates a NACK to its previous hop.
>     data NACK seems to me not understood as fully:
>     a) if a consumer gets a data packet that's not what it wants, it'd
>     retry the interest in some way;
>     b) any other forwarding node could drop an incorrect data packet, it
>     can; whether it should generate a NACK on behalf of the consumer
>     seems a separable question.
>
>
>      > On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee
>     <tnsr.chatterjee at gmail.com> wrote:
>      >
>      > If a data packet is modified and detected during verification,
>     can forwarder send a NACK. How the data can be resend in this case?
>     If consumer is not satisfied it has to send the same interest again,
>     is there any other way out to get the data which may not been
>     correctly received due to some modification.
>      >
>      > -- Regards,
>      > Tanusree Chatterjee
>      >
>      > _______________________________________________
>      > Ndn-interest mailing list
>      > Ndn-interest at lists.cs.ucla.edu
>      > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>     _______________________________________________
>     Ndn-interest mailing list
>     Ndn-interest at lists.cs.ucla.edu
>     http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>