<div dir="ltr">I will also add that if you're doing UDP, and want consistency over the existing internet - I'd suggest 4k, as any UDP packets larger than that risk being filtered by existing IP-based systems<div><div><br></div><div>IE - early testbed ndnvideo app box would not route to UIUC app box unless packet size was 3800 bytes (enough for 4k overhead) </div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 4:56 PM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Klaus<br><br></div><div>The setting of 8800 octets is indeed based on the reasons given by Nick Briggs, which he posted to CCNx mailing list years ago. But that doesn't answer why 8800 octets is a limit in the code rather than a recommendation.<br></div><div><br></div><div>The reason for having the practical limit is to reduce memory usage.<br>To receive a packet via socket API, NFD needs to allocate a buffer before asking the kernel to copy the packet into this buffer. Since the packet size is unknown at that time, NFD allocates a buffer of 8800 octets.<br>After the packet is received, assuming it is not fragmented by NDNLP, the buffer stays around as long as the packet is needed (in PIT or CS), even if the packet is much smaller than 8800 octets. The alternative would be truncating the buffer to fit the actual packet size, but that involves another copying, and we decide to save a copying at the expense of wasting some memory (the difference between 8800 octets and the actual packet size).<br></div><div>Suppose we increase the practical limit to 1MB, NFD would allocate a 1MB packet before receiving a packet. If most packets we are dealing with is much smaller than 1MB, a lot of memory will be wasted.<br></div><div><br></div>Yours, Junxiao<br><div><div><span><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 2:40 PM, Nick Briggs <span dir="ltr"><<a href="mailto:nicholas.h.briggs@gmail.com" target="_blank">nicholas.h.briggs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It gets you 8K bytes of data along with necessary metadata and a name that isn't too long in a Content packet.<br>
It can be encapsulated in a UDP packet with about 6 fragments when you're do IP encapsulation. (max UDP is 64K bytes)<br>
It fits within a 9000 byte jumbo ethernet frame if you're doing direct ethernet encapsulation.<br>
<span class="m_-8180376356136916841m_-8796630140644164229m_-3224170520104798569gmail-HOEnZb"><font color="#888888"><br>
-- Nick Briggs</font></span><br></blockquote></div></div></span><span><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 2:35 PM, Klaus Schneider <span dir="ltr"><<a href="mailto:klaus@cs.arizona.edu" target="_blank">klaus@cs.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Btw, what was the reason for setting the default max packet size to 8800 in the first place?<br>
<br>
Is there any drawback to increasing the default, to let's say 1 Megabyte?<br>
<br>
Best regards,<br>
Klaus<span></span><br></blockquote></div></div></span></div></div></div>
<br>______________________________<wbr>_________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/m<wbr>ailman/listinfo/ndn-interest</a><br>
<br></blockquote></div><br></div></div></div>