[Nfd-dev] Network Nack Usage

[Alex Afanasyev]

The exact details on how consumer app should react for the incoming network NACK is a good question.  In the sample applications that we have (catchunks), we simple abort and visualize the error.

The behavior should be definitely from timeout in cases when timeout action includes immediate retransmit.  Otherwise, there would be a lot of packet flow generated (interest, nack, interest, nack, etc.)  Beyond that, I cannot say much.  We need more use cases to see what should be done.

--
Alex

> On May 5, 2016, at 4:59 PM, Brown, Andrew <andrew.brown at intel.com> wrote:
> 
> Thanks Alex for the note on Lixia’s point 2 below; I was referring more to point 1. I wanted to know specifically not if anyone is using the application-level Nack but the network-level one that is exposed in the APIs. I will take the absence of comments to mean that this is yet to be used. <>
> 
> Sincerely,
> 
> Andrew Brown
> IoTG Strategy and Integrated Products
> 
>  <>From: Lixia Zhang [mailto:lixia at cs.ucla.edu]
> Sent: Tuesday, May 3, 2016 12:14 PM
> To: Brown, Andrew <andrew.brown at intel.com>
> Cc: nfd-dev at lists.cs.ucla.edu; Ilya Moiseenko <iliamo at mailbox.org>
> Subject: Re: [Nfd-dev] Network Nack Usage
> 
> 
> On May 3, 2016, at 8:58 AM, Brown, Andrew <andrew.brown at intel.com <mailto:andrew.brown at intel.com>> wrote:
> 
> All,
> 
> Is anyone using the different NACK codes to alter the flow of their application?
> 
> there could be different ways to interpret the question:
> 
> 1/ how applications use different NACK codes to alter the "data flow"
> e.g. Ilya (copied him here) used application NACK to tell consumers to wait for a specific time period when data is not ready
> 
> 2/ how network layer (NFD) use different NACKs to alter the paths of dat flows
> (as Alex mentioned)
> 
> 
> I am looking at https://github.com/named-data/jndn/commit/f0a50c635afe0cbd27cc84e188b582eb7e457b9b#diff-e12e36065baf92aa80b384cbfb3eef02R35 <https://github.com/named-data/jndn/commit/f0a50c635afe0cbd27cc84e188b582eb7e457b9b#diff-e12e36065baf92aa80b384cbfb3eef02R35> and was interested in finding out the different actions others are taking: obviously log in all cases, wait and re-send for congestion, fail and throw for no route, ___ for duplicate?
> 
> Sincerely,
> 
> Andrew Brown
> IoTG Strategy and Integrated Products
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160505/fb0176e5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160505/fb0176e5/attachment.bin>