[Ndn-interest] How sending an interest for each chunk is justified?

[Marc.Mosko at parc.com]

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.

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.

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.

[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.
[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.

Marc

On Jul 7, 2016, at 10:45 AM, Zeinab Zali <zeinabzali at gmail.com<mailto:zeinabzali at gmail.com>> wrote:

Dear professor Zhang,

Thanks a lot for your instant reply. Yes you got my intention and explained the reply perfectly.

"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."

This explanation justified me.

Best,

On Thu, Jul 7, 2016 at 8:23 PM, Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>> wrote:

On Jul 7, 2016, at 6:41 AM, Zeinab Zali <zeinabzali at gmail.com<mailto:zeinabzali at gmail.com>> wrote:

Dear all,

There is a serious question in my mind about NDN architecture and method. Is sending an interest for each chunk 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?

Dear Zeinab,

thanks for bringing up the question. I tried to fully understand it before commenting: you asked:
    "Is sending an interest for each chunk is efficient?"
this implies to me that you worry about sending more interest packets than necessary -- is that right?

If so,
- 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)
- one of the many functions that interest-data exchange provides is loss recovery
- 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?

Lixia
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.

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160707/d86f6057/attachment.html>