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

[Lixia Zhang]

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.

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.

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.

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

> On Jul 7, 2016, at 3:30 PM, Marc.Mosko at parc.com wrote:
> 
> 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/20160708/c1eab668/attachment.html>