<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;" class=""><div class="">We often talk about "learn how to think architecturally", so we can try it on this specific example, to sort out what may be architecture, what may be engineering, or how one may look at performance of different architectures.<div class=""><br class=""><div class="">1/ apps have their own units of data, like a file; network layer packets have their own MTU limit because packet is unit of loss recovery, and because a network is shared and too big a packet could cause excessive delays on others.  These network basics hold true in both IP and NDN networks.</div><div class=""><br class=""></div><div class="">2/ With these basic concepts: one can do a great deal of engineering to optimize certain performance metrics. TCP acking every other segment is such an example; it's still consistent with the requirement that network packets operate on network data unit.</div></div><div class=""><br class=""></div><div class="">3/ It is very true that, at this time, NDN interest size can be a lot bigger than a TCP ACK, but that does not mean the interest size cannot get smaller, nor does it imply an NDN network less efficient (as the stateful forwarding by the interest-data exchange improves network efficiency in some fundamental ways that a stateless IP data plane cannot do).</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jul 7, 2016, at 3:30 PM, <a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a> wrote:</div><br class="Apple-interchange-newline"><div class="">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">

<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">I would note, however, that TCP does not require an ACK for every segment.  One usually sends every 2 packets, or even more.  So while one would not “work on file granularity” (for a big file), one could have a very large window and infrequent
 ACKs in TCP while keeping each segment MTU size.  An ACK only needs the IP addresses and a TCP header.  A TCP ACK has 40 bytes of IPv6 header plus 20 bytes of TCP header (total 60 bytes) per 2880 bytes of payload (2x 1500 - 2x 60). Therefore, one must be careful
 of how much information is put in an Interest to request each segment.</div>
<div class=""><br class="">
</div>
<div class="">An Interest may have a much larger size than 60 byte.  For parity with TCP, one would need no more than 30 byte interest per 1500 byte packet [1].  A 30 byte NDN interest (excluding NDNLP) means for a 5-component name you only have about 9 bytes
 of data per name component considering TLV encapsulation [2].  It also means you don’t have KeyID restrictions or hash restrictions in the name or selectors.  Also, the data needs to echo back the name (or even a longer name), so you only get 1500 - TLV overhead
 & name overhead (66 bytes without any SignatureInfo or SignatureValue) = 1434 bytes per packet.</div>
<div class=""><br class="">
</div>
<div class="">So, as long as Interest size is around that size, you have parity with TCP6 on the upstream bandwidth.  As long as the TLV encoding and name are on par with the IPv6/TCP headers, you have downstream parity.</div>
<div class=""><br class="">
</div>
<div class="">[1] One could use a larger MTU with fragmentation if you are willing to pay fragmentation overhead.  But this could be done with TCP too.</div>
[2] I computed this as Interest TLV (2 bytes), Name TLV (2 bytes), 5x name component (10 bytes) gives 46 bytes of name, so 46 / 5 = 9.2 bytes per name component.
<div class=""><br class="">
</div>
<div class="">Marc<br class="">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jul 7, 2016, at 10:45 AM, Zeinab Zali <<a href="mailto:zeinabzali@gmail.com" class="">zeinabzali@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class=""><span style="font-size:12.8px" class="">Dear professor Zhang,</span></div>
<div class=""><span style="font-size:12.8px" class=""><br class="">
</span></div>
<div class=""><span style="font-size:12.8px" class="">Thanks a lot for your instant reply. Yes you got my intention and explained the reply perfectly.</span></div>
<div class=""><span style="font-size:12.8px" class=""><br class="">
</span></div>
<span style="font-size:12.8px" class="">"You must know that a TCP connection also has packets going both directions, for the same purpose.  There is no attempt to </span>
<div class=""><span style="font-size:12.8px" class="">reduce TCP ack overhead by making TCP Ack to work on a file granularity."</span><br class="">
</div>
<div class=""><span style="font-size:12.8px" class=""><br class="">
</span></div>
<div class=""><span style="font-size:12.8px" class="">This explanation justified me. </span></div>
<div class=""><span style="font-size:12.8px" class=""><br class="">
</span></div>
<div class=""><span style="font-size:12.8px" class="">Best,</span></div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Thu, Jul 7, 2016 at 8:23 PM, Lixia Zhang <span dir="ltr" class="">
<<a href="mailto:lixia@cs.ucla.edu" target="_blank" class="">lixia@cs.ucla.edu</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class=""><br class="">
<div class=""><span class="">
<blockquote type="cite" class="">
<div class="">On Jul 7, 2016, at 6:41 AM, Zeinab Zali <<a href="mailto:zeinabzali@gmail.com" target="_blank" class="">zeinabzali@gmail.com</a>> wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">Dear all,
<div class=""><br class="">
</div>
<div class="">There is a serious question in my mind about NDN architecture and method. Is sending
<b class="">an interest for each chunk </b>is efficient? In this way, for a large file lots of interest should be sent with all the security and communication (or even may be routing and forwarding) overhead. How It is justified? Is there a discussion in the
 literature about it?</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
</span>Dear Zeinab,</div>
<div class=""><br class="">
</div>
<div class="">thanks for bringing up the question. I tried to fully understand it before commenting: you asked:</div>
<span class="">
<div class="">    "Is sending <b class="">an interest for each chunk </b>is efficient?"</div>
</span>
<div class="">this implies to me that you worry about sending more interest packets than necessary -- is that right?</div>
<div class=""><br class="">
</div>
<div class="">If so,</div>
<div class="">- keen in mind we are talking about a network layer protocol here (network packet must have a MTU size that prevents a single packet blocking others for too long)</div>
<div class="">- one of the many functions that interest-data exchange provides is loss recovery</div>
<div class="">- if one sent an interest per big file, wouldn't that make the whole file as the unit of loss recovery?  Would that be efficient?</div>
<span class="HOEnZb"><font color="#888888" class="">
<div class=""><br class="">
</div>
<div class="">Lixia</div>
</font></span>
<div class="">PS: You must know that a TCP connection also has packets going both directions, for the same purpose.  There is no attempt to reduce TCP ack overhead by making TCP Ack to work on a file granularity.</div></div></blockquote></div>
</div>
_______________________________________________<br class="">
Ndn-interest mailing list<br class="">
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>

</div></blockquote></div><br class=""></div></body></html>