<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello Junxiao</p>
    <p><br>
    </p>
    <p>Your guess was correct!! The producer application is killed after
      a while, though I'm still not sure why. I was able to verify that
      by running the experiment and checking the running processes with
      htop. I tried to catch any exceptions on the application or any
      exit points but there aren't any. Also checked the syslog to try
      to find out why they are being killed but it is still a mystery. I
      will write a following email if I find out why they are being
      killed, but I might just create some sort of application to
      relaunch the producers if they die.<br>
    </p>
    <p>Also, on my other computer, this issue does not happen. The
      producer applications run all the way though the experiment
      resulting in 0 NACKs. Both setups are using a VirtualBox VM
      created by the vagrantfile but they do run on different hardware.<br>
    </p>
    <p><br>
    </p>
    <p>Thank you so much for the insight!</p>
    <p><br>
    </p>
    <p>Best regards,</p>
    <p>André Dexheimer Carneiro<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2/4/21 1:40 PM, Junxiao Shi wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOFH+OZXUZ1hTTj=zn3JETPNeqOijk_evajoV2FQb3u+jU_0UA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Hi Andre</div>
        <div><br>
        </div>
        <div>Each Nack reason has a different meaning. I have seen too
          many people bashing Nack in general without understanding the
          difference between reason codes.</div>
        <div><br>
        </div>
        <div><font face="monospace">$ grep onIncomingNack $(find -name
            nfd.log) | awk '{ split($6,a,"~"); print a[length(a)] }'  |
            sort | uniq -c</font></div>
        <div><font face="monospace">    163 Duplicate<br>
              12648 NoRoute<br>
          </font></div>
        <div><font face="monospace">$ grep onOutgoingNack $(find -name
            nfd.log) | awk '{ split($6,a,"~"); print a[length(a)] }'  |
            sort | uniq -c<br>
                161 Duplicate<br>
              15577 NoRoute<br>
          </font></div>
        <div><br>
        </div>
        <div>
          <div>I can see that you are getting mostly Nack~NoRoute
            packets. These are generated if a forwarder receives an
            Interest but cannot find a matching FIB entry.</div>
          <div><br>
          </div>
        </div>
        <div>In v1/log/nfd.log, I found the following:</div>
        <div><font face="monospace">1612407736.138128 DEBUG:
            [nfd.Forwarder] onIncomingInterest in=(269,0)
            interest=/ndn/v1-site/v1/C2Data-1891-Type3<br>
            1612407736.138181 DEBUG: [nfd.Forwarder] onContentStoreMiss
            interest=/ndn/v1-site/v1/C2Data-1891-Type3<br>
            1612407736.138228 DEBUG: [nfd.Forwarder] onOutgoingNack
            out=269 nack=/ndn/v1-site/v1/C2Data-1891-Type3~NoRoute OK<br>
            1612407736.138329 DEBUG: [nfd.Forwarder] onInterestFinalize
            interest=/ndn/v1-site/v1/C2Data-1891-Type3 unsatisfied<br>
          </font></div>
        <div><br>
        </div>
        <div>I see that face 274 is responsible for this prefix:</div>
        <div><font face="monospace">1612407674.566604  INFO:
            [nfd.RibManager] Adding route /ndn/v1-site/v1 nexthop=274
            origin=app cost=0<br>
          </font></div>
        <div><br>
        </div>
        <div>However, the face was closed before the above Interest:</div>
        <div><font face="monospace">1612407735.703876  INFO:
            [nfd.Transport]
            [id=274,local=unix:///run/v1.sock,remote=fd://164] setState
            UP -> CLOSING<br>
            1612407735.703902  INFO: [nfd.Transport]
            [id=274,local=unix:///run/v1.sock,remote=fd://164] setState
            CLOSING -> CLOSED<br>
            1612407735.704135  INFO: [nfd.FaceTable] Removed face id=274
            remote=fd://164 local=unix:///run/v1.sock<br>
            1612407735.704327 DEBUG: [nfd.RibManager] Received
            notification for destroyed FaceId 274<br>
            1612407735.704432 DEBUG: [nfd.Readvertise] remove-route
            /ndn/v1-site/v1(274,app) not-readvertised<br>
          </font></div>
        <div><br>
        </div>
        <div>My guess is that the producer application has crashed, so
          that all subsequent Interests do not have a FIB match and thus
          get Nacks.</div>
        <div><br>
        </div>
        Yours, Junxiao
        <div><br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Wed, Feb 3, 2021 at
              10:31 PM Andre via Mini-NDN <<a
                href="mailto:mini-ndn@lists.cs.ucla.edu"
                moz-do-not-send="true">mini-ndn@lists.cs.ucla.edu</a>>
              wrote:</div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div>
                <p>I forgot to mention the NLSR sleep though I did try a
                  few different values for it, between 40 and 200
                  seconds. Going lower than that did make it worse, but
                  in that range it does not make much difference.</p>
                <p><br>
                </p>
                <p>Testing a bit further now, it seems that the
                  probability of getting a NACK increased over time,
                  pretty much all hosts got the data in the first few
                  transmissions and then started getting more and more
                  NACKs.</p>
                <p><br>
                </p>
                <p>I tested some producer-consumer pairs in the CLI
                  after the script had run, and there does not seem to
                  be an issue with connectivity between the hosts, even
                  in the cases where there were NACKs. Is there another
                  way to test it, or is this method right?</p>
                <p><br>
                </p>
                <p>I attached the .conf topology file I'm using to the
                  email as well as the debug logs for NFD and NLSR for
                  all nodes. There is also this graph that represents
                  the topology.</p>
                <p><br>
                </p>
                <p><img src="cid:part2.3E5D6572.28B1EF5F@inf.ufrgs.br"
                    alt="" class="" width="942" height="484"></p>
                <p><br>
                </p>
              </div>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
  </body>
</html>