<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=""><br class=""><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>> <<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].  </div></div></div></blockquote><div><br class=""></div><div>While TCP of course can use larger MTU sizes and use it if they are available.  The problems is that the problems with IP fragmentation (e.g., loss of a single fragment invalidates the whole packet) de-incentivizes packets larger MTU, which in turn creates no incentives to increase MTU in the network.  Moreover, the overhead ratio is acceptable, so there is no much pressure to do that.</div><div><br class=""></div><div>In ICN/NDN things are different. There are larger overheads: names may take more space, unlike fixed size IP addresses, signatures take another big chunk of space in data packets.  To get acceptable level overhead, one would want to use larger packet sizes.  This would be a good push to increase MTU sizes (I'm just speculating, but 4-8k may be reasonable in many cases).   Having transparent hop-by-hop fragmentation (<a href="http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/" class="">http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/</a>) is another incentive and push to increase MTU in the network where possible.</div><div><br class=""></div><div>--</div><div>Alex</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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></div></blockquote><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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>
<br class="">
</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>

_______________________________________________<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="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br class=""></div></blockquote></div><br class=""></body></html>