<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Yusung,</div><div><br></div><div>Let me clarify what I meant by the question. Let's say that the implicit digest component is calculated (hopefully fully defined and standardized way) by the NDN layer, based on the content of a packet. If a client wants to request something using the implicit component, it needs to know this component. BUT, to know this digest, somebody needs to tell what this digest is. And I don't see how exactly this part can be put inside the protocol.</div><div><br></div><div>There is a special use of implicit component that can be put inside the protocol, but it is related to excluding the packet using the implicit digest, not using digest to request exact data packet. For example, a consumer can request /prefix/data and get some data packet that corresponds to this name. If the consumer after the reception of the packet figure out that it is not the packet it was looking for, it can send a new interest, excluding the received data packet based on the implicit digest component.</div><div><br></div><div>---</div><div>Alex </div><br><div><div>On Apr 3, 2013, at 7:54 PM, Yusung Kim <<a href="mailto:yskim525@gmail.com">yskim525@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Alex, <div><br></div><div>Yes I agree that it is an important issue. </div><div><br></div><div>For the last question, </div><div>"if a producer does not consider the digest component, how do the customer will figure out it?"</div>
<div><br></div><div>In CCNx, the implicit digest component seems to be created and notified by a CCN library rather than an application itself, right ?</div><div style=""><br></div><div style="">If the process is going to be in a standard protocol such as TCP ( at a separated layer ), it could be automatically handled without a consumer's <i class="" tabindex="0" title="보조사전 보기" lang="en" style="font-size: 13px; font-family: Arial; font-style: normal; display: inline-block; line-height: 17px; ">participation</i><i class="" tabindex="0" title="보조사전 보기" lang="en" style="font-size: 13px; font-family: Arial; font-style: normal; display: inline-block; line-height: 17px; ">.</i></div>
<div style="">otherwise, we may use such a protocol at a library ( like the implementation in CCNx ) or design it at application-layer <i class="" tabindex="0" title="보조사전 보기" lang="en" style="font-family: Arial; font-size: 13px; font-style: normal; display: inline-block; line-height: 17px; ">individually</i>.</div>
<div style=""><br></div><div style=""><font face="Arial"><span style="line-height:16.988636016845703px">It's very useful discussion on the digest component.</span></font></div><div style=""><font face="Arial"><span style="line-height:16.988636016845703px">I appreciate your kind comment.</span></font></div>
<div style=""><font face="Arial"><span style="line-height:16.988636016845703px"><br></span></font></div><div style=""><font face="Arial"><span style="line-height:16.988636016845703px">Thank you,</span></font></div>
<div style=""><i class="" tabindex="0" title="보조사전 보기" lang="en" style="font-size: 13px; font-family: Arial; font-style: normal; display: inline-block; line-height: 17px; "><br></i></div><div style=""><font face="Arial"><span style="line-height:16.988636016845703px">- Yusung Kim -</span></font></div>
<div style=""><i class="" tabindex="0" title="보조사전 보기" lang="en" style="font-size: 13px; font-family: Arial; font-style: normal; display: inline-block; line-height: 17px; "><br></i></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 3:55 AM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi Yusung,<div><br></div><div>It may not be that big of a disadvantage, but it is relatively serious requirement for the architecture, raising several questions. What exactly is this digest a hash of? The content? The packet? Some other data? Which digest algorithm suits best for everybody using the architecture? If producers don't consider (directly or indirectly) the digest component, how do the customers will figure out what is the digest to be put in the Interest?</div>
<div><br></div><div>The last question, at least for me, is one of the major problems of having the implicit component. Yes, it is good to have ability to uniquely identify the data you want to get, but how exactly can you figure out this implicit digest before you got the data (or before data is actually produced).</div>
<div><br></div><div>---</div><div>Alex</div><div><div class="h5"><br><div><div>On Apr 2, 2013, at 10:35 PM, Yusung Kim <<a href="mailto:yskim525@gmail.com" target="_blank">yskim525@gmail.com</a>> wrote:</div><br>
<blockquote type="cite"><div dir="ltr">Hi Alex, <div><br></div><div>Thank you for your comment.</div><div>I agree your explanation.</div><div><br></div><div>By the way, would you tell me why you consider it as a "big" disadvantage ? </div>
<div><br></div><div>When using the implicit digest component, </div><div>a producer or an application developer does not need to consider the digest component.</div><div>It seems to be easy to develop applications over NDN.</div>
<div><br></div><div>What is a negative effect on using the implicit digest component?</div><div><br></div><div>- Yusung Kim -<br></div><div><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 3:08 AM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Hi Yusung,</div><div><br></div><div>The answer is of course NO, since the Interests specifies one name, but the available data has different (does not matter implicit or explicit component) name.</div>
<div><br></div><div>What I'm seeing as advantage (and a "big" disadvantage at the same time) of using the implicit digest component is that routers are required to calculate this component based on the content. This prevents a producer from "lying" and setting one explicit digest, while the content corresponds to a completely different digest.</div>
<div><br></div><div>---</div><div>Alex</div><div><br><div><div>On Apr 1, 2013, at 6:31 PM, Yusung Kim <<a href="mailto:yskim525@gmail.com" target="_blank">yskim525@gmail.com</a>> wrote:</div><br><blockquote type="cite">
Hi Alex, <div><br></div><div>It's right, each individual piece of content should have a unique name in NDN.</div><div><br></div><div>We may explicitly add a digest component to the name as following;</div><div> </div>
<div>1) /<a href="http://domain.com/video1.avi/sequence_num/" target="_blank">domain.com/video1.avi/sequence_num/</a><b>explicit_producer1_digest </b></div><div>2) /<a href="http://domain.com/video1.avi/sequence_num/" target="_blank">domain.com/video1.avi/sequence_num/</a><b>explicit_producer2_digest</b></div>
<div><br></div><div><br></div><div>When User1 retrieved content by using the name 1) and the data is cached at routers ,</div><div>if User2 sends an interest packet with the name 2), the interest cannot be served from the Content Store since the cache was stored by the name 1)</div>
<div><br></div><div><br></div><div>How about using the implicit digest ?</div><div><br></div><div><div>3) /<a href="http://domain.com/video1.avi/sequence_num/" target="_blank">domain.com/video1.avi/sequence_num/</a><b>implicit_producer1_digest </b></div>
<div>4) /<a href="http://domain.com/video1.avi/sequence_num/" target="_blank">domain.com/video1.avi/sequence_num/</a><b>implicit_producer2_digest</b></div></div><div><b><br></b></div><div>Once User1 retrieved content by using the name 3), </div>
<div>Could User2 retrieve the cached data, even though User2 sends an interest with the name 4) ?</div><div><br></div><div>If the answer is NO, what is the merit using the implicit digest instead of the explicit digest?</div>
<div><br></div><div>Thank you,</div><div><br></div><div>- Yusung Kim -</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Mon, Apr 1, 2013 at 11:58 AM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi Yusung,</div><div><br></div><div>No, ndnSIM (as of right now) does not have a concept of the implicit digest. Ideally, each individual piece of content should have a unique name. If you really want to distinguish between data produced by Producer1 and Producer2, why not explicitly name these two data pieces differently? Alternatively, you can explicitly add a digest component to the name.</div>
<div><br></div><div>---</div><div>Alex</div><div><br><div><div>On Mar 31, 2013, at 7:50 PM, Yusung Kim <<a href="mailto:yskim525@gmail.com" target="_blank">yskim525@gmail.com</a>> wrote:</div><br><blockquote type="cite">
Hi Alex and ndnSIM community.<div><br></div><div>When using ndnSIM, is there the same function of the implicit digest to get specific content ?</div><div>( the implicit digest is used in CCNx, right ? )</div><div><br></div>
<div>In the your example topology, </div><div>Does Consumer need to select one producer between Producer1 and Producer2 using the implicit digest ?</div><div><br></div><div>Thanks,</div><div><br></div><div>- Yusung Kim -</div>
<div><br></div><div><br><br><div class="gmail_quote">On Mon, Apr 1, 2013 at 4:11 AM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi Amin,</div><div><br></div><div>Let me clarify a little bit with a small example:</div>
<div><br></div><div>Consumer --- Router ----- Producer1</div><div> |</div><div> +--------- Producer2</div><div><br></div><div>Assuming ns3::ndn::fw::Flooding strategy, Interests from the Consumer will reach both Producer1 and Producer2, and they both will send back a content object packet.</div>
<div><br></div><div>Router, receiving the first packet (depending on the topology, could be from Producer1 or Producer2) will forward it to the consumer and remove* the PIT entry. When the second content object arrives to the Router (not the consumer), it will be discarded by the router, as unsolicited. (I would not call this as a drop, since it is relatively high-level decision to not forward the specific packet.)</div>
<div><br></div><div>* PIT entry can be immediately removed (by default), or scheduled for removal within a short time interval (PitEntryPruningTimout). In either case, an extra content object will be discarded.</div><div>
<br></div><div>---</div><div>Alex</div><div><br></div><div><div>On Mar 31, 2013, at 12:02 PM, Amin Karami <<a href="mailto:amin@ac.upc.edu" target="_blank">amin@ac.upc.edu</a>> wrote:</div><br><blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div>In case of ns3::ndn::fw::Flooding, we
will have several drops. Because when a consumer receives desired
content from first sender/producer, consumer will drop other same
contents. Yes? because the desired Interest has been satisfied and
removed from PIT.<br>
<br>
<br>
/Amin<div><br>
<br>
<br>
On 03/31/2013 08:42 ب.ظ, Alex Afanasyev wrote:<br>
</div></div><div>
<blockquote type="cite">
<div>Hi Amin,</div>
<div><br>
</div>
<div>I is possible, but it depends on the forwarding strategy to
deliver Interests to different producers. For example, if you
choose ns3::ndn::fw::BestRoute, then Interests will only be
delivered over the "shortest-metric" path and some of the
producers will never see the Interests. If you use
ns3::ndn::fw::Flooding, then all of the producers will receive
Interests and it would depend on network topology
(delays/losses) content object from which exactly producer will
reach the consumer.</div>
<div><br>
</div>
<div>In case if you have several consumers, depending on topology
and forwarding strategy, they may be getting content objects
from different producers.</div>
<div><br>
</div>
<div>If you want only some Interests be satisfied by one producers
and other by another, you may need to amend ndn::Producer
implementation (or better create a new custom Producer app) by
adding the appropriate logic.</div>
<div><br>
</div>
<div>---</div>
<div>Alex</div>
<br>
<div>
<div>On Mar 31, 2013, at 11:35 AM, Amin Karami <<a href="mailto:amin@ac.upc.edu" target="_blank">amin@ac.upc.edu</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"> Hi friends,<br>
Is it possible to satisfy sent Interests from a consumer
with more than one producer?<br>
for example, does the following code work correctly to
satisfy Interests in /dst1 namespace with three producers?<br>
<pre style="overflow-x:auto;overflow-y:hidden;padding:5px;line-height:14px;border-top-width:1px;border-bottom-width:1px;border-style:solid none;border-top-color:rgb(170,204,153);border-bottom-color:rgb(170,204,153);font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px"><span style="background-color:rgb(255,255,136)"><span> ndnGlobalRoutingHelper</span><span>.</span><span>AddOrigins</span> <span>(</span><span style="color:rgb(64,112,160)">"/dst1"</span><span>,</span> <span>producer1</span><span>);</span>
</span><span style="background-color:rgb(255,255,136)"> <span>producerHelper</span><span>.</span><span>SetPrefix</span> <span>(</span><span style="color:rgb(64,112,160)">"/dst1"</span><span>);</span>
</span><span style="background-color:rgb(255,255,136)"> <span>producerHelper</span><span>.</span><span>Install</span> <span>(</span><span>producer1</span><span>);
</span> </span>
<span style="background-color:rgb(255,255,136)"><span> ndnGlobalRoutingHelper</span><span>.</span><span>AddOrigins</span> <span>(</span><span style="color:rgb(64,112,160)">"/dst1"</span><span>,</span> <span>producer2</span><span>);</span>
</span><span style="background-color:rgb(255,255,136)"> <span>producerHelper</span><span>.</span><span>SetPrefix</span> <span>(</span><span style="color:rgb(64,112,160)">"/dst1"</span><span>);</span>
</span><span style="background-color:rgb(255,255,136)"> <span>producerHelper</span><span>.</span><span>Install</span> <span>(</span><span>producer2</span><span>);</span></span>
<span style="background-color:rgb(255,255,136)"><span> ndnGlobalRoutingHelper</span><span>.</span><span>AddOrigins</span> <span>(</span><span style="color:rgb(64,112,160)">"/dst1"</span><span>,</span> <span>producer3</span><span>);</span>
</span><span style="background-color:rgb(255,255,136)"> <span>producerHelper</span><span>.</span><span>SetPrefix</span> <span>(</span><span style="color:rgb(64,112,160)">"/dst1"</span><span>);</span>
</span><span style="background-color:rgb(255,255,136)"> <span>producerHelper</span><span>.</span><span>Install</span> <span>(</span><span>producer3</span><span>);</span></span>
</pre>
<br>
Best Regards,<br>
/Amin<br>
<br>
</div>
_______________________________________________<br>
ndnSIM mailing list<br>
<a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
</div><div>-- <br><p><font style="font-size:10pt" face="Verdana"><font color="#666666">
<br>
Best Regards,<br>
<br>
=======================================================<br>
Amin Karami, PhD student in Computer Architecture Department
(DAC) at<br>
the Universitat Politècnica de Catalunya Barcelona Tech
(UPC)<br>
<br>
e-mail: </font> <a href="mailto:amin@ac.upc.edu" style="text-decoration:none" target="_blank">
<font color="#666666">amin@ac.upc.edu</font></a><font color="#666666"> | UPC-Campus Nord., Office: C6-E102<br>
phone: +34 93 40 11 638 | Jordi Girona, 1-3<br>
</font>
</font><font color="#666666"><font style="font-size:9pt" face="Verdana"> </font>
<font face="Verdana"> </font><font style="font-size:9pt" face="Verdana"> </font>
</font><font style="font-size:10pt" face="Verdana"><font color="#666666">| 08034 Barcelona - SPAIN<br>
WWW: </font> <a href="http://personals.ac.upc.edu/amin/" style="text-decoration:none" target="_blank">
<font color="#666666">http://personals.ac.upc.edu/amin/</font></a><font color="#666666"><br>
=======================================================<br>
</font></font></p>
</div>
</div>
</blockquote></div><br></div><br>_______________________________________________<br>
ndnSIM mailing list<br>
<a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote></div><br></div></div></blockquote></div><br></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote></div><br></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu">ndnSIM@lists.cs.ucla.edu</a><br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim<br></blockquote></div><br></body></html>