<div dir="ltr">Hi John<br><div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2.  The content store still seems to be caching them as separate content items!  Even if there are say, 20 different requests for /prefix/%FE%01?...  they are each apparently cached separately.</div></div></blockquote><div>How do you know that? If you have logs, paste a snippet of relevant logs.<br></div><div>Short logs (less than 200 lines) should be pasted on email body. Long logs should be uploaded to Gist or PasteBin. Do not send logs as attachments.<br></div><div>See also <a href="http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/001748.html">http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/001748.html</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><b>4.  Is ensuring duplicates aren't cached something that the Policy must take care of?  (immediately evict an entry with the same /prefix/seqNumber and/or /prefix/suffix ??</b></div></div></blockquote>No. Assuming there is only one producer creating the requested Data, subsequent Interests for the same Data should match the existing CS entry and should not be forwarded again.<br></div><div class="gmail_quote">If you are sending multiple Interests with the same name from multiple consumers located in sparse locations, and there are multiple producers, it is possible that each producer can generate a different Data, and those Data could be cached separately. Remember that the Data name ends with an implicit digest, and signing the same name+payload multiple times will generate different signatures and thus different implicit digests, even if those producers are using the same signing key.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Yours, Junxiao<br></div></div></div></div>