[Ndn-interest] NDN Stack

Ahmed BENMOUSSA ah.benmoussa at lagh-univ.dz
Tue Aug 6 08:56:37 PDT 2019


You are right, Wentao. The definition of "reliable communication" is very
different from that of TCP/IP.
Adding a "*Transport*" layer makes perfect sense in this case.

Now, I am wondering if we should consider adding a "*Transport*" layer to
our papers and presentations.
What NDN stack should we adopt for future works?

Thank you.
Ahmed.

Le mar. 6 août 2019 à 16:45, WENTAO SHANG <wentaoshang at ucla.edu> a écrit :

>
>
> On Tue, Aug 6, 2019, 4:34 AM Ahmed BENMOUSSA <ah.benmoussa at lagh-univ.dz>
> wrote:
>
>> Dear Klaus,
>>
>> *Note that the first one has the transport layer grayed out and explains*
>>
>> *"transport functions are implemented in system libraries used by *
>> *applications*".
>>
>> Yes, in the first paper the "Transport" layer is grayed out.
>> It is presented as a sub-layer of the "Application" layer.
>> When I first read the paper, I found this approach of the NDN stack
>> right.
>> What confused me, is the second paper (published after the first one).
>> In the second paper, the authors separated the "Transport" layer from
>> the "Application" layer. (Two authors shares the first and the second
>> paper).
>>
>>
>> Dear Wentao Shang,
>> Thank you for your response.
>>
>> *"the NDN layer by itself is best-effort only, so applications often need*
>>
>> * an additional layer to provide some form of stronger guarantees, or
>> "reliability", *
>> *in data delivery, such as eventual consistency" *
>>
>> Yes, I understand your point. But if the actual NDN uses IP protocols
>> (e.g. TCP)
>> as link-layer tunnels, why add another layer to guarantee reliability?
>> Or this layer will be used when NDN is natively deployed (i.e. without
>> using IP protocols)?
>>
>
> Two reasons:
>
> First, like Klaus said earlier, the tunnels on our testbed only connect
> NDN nodes in one-hop distance. Anything can go wrong when the communication
> spans across multiple hops: interests may time out, cache may be cleared,
> nodes may crash, etc. So we still need a higher level protocol that works
> regardless of the property of the underlying tunnels.
>
> Second, NDN is information-centric so the definition of "reliable
> communication" is very different from that of TCP/IP. Take the sync
> protocols as an example: instead of worrying about moving bytes reliably
> from node A to node B, sync is designed to reliably synchronize distributed
> data collections that can be modified concurrently by multiple data
> producers, which is a much more important problem for content centric
> architectures.
>
> Wentao
>
>
>> Best regards,
>> Ahmed B.
>>
>>
>> Le mar. 6 août 2019 à 03:56, Klaus Schneider <klaus at cs.arizona.edu> a
>> écrit :
>>
>>>
>>>
>>> On 8/5/19 3:07 PM, Ahmed BENMOUSSA wrote:
>>> > Hello Klaus,
>>> > Thank you for your response.
>>> >
>>> > These two papers used the above-mentioned stack:
>>> >
>>> > *NDN Host Model*:
>>> https://named-data.net/publications/sigcomm-ccr-final221/
>>>
>>> Note that the first one has the transport layer grayed out and explains
>>> "transport functions are implemented in system libraries used by
>>> applications".
>>>
>>>
>>> > *DDoS mitigation by FITT in NDN*:
>>> >
>>> https://www.researchgate.net/publication/331343472_Expect_More_from_the_Networking_DDoS_Mitigation_by_FITT_in_Named_Data_Networking
>>> >
>>> > Best regards,
>>> > Ahmed B.
>>> >
>>> >
>>> > Le lun. 5 août 2019 à 23:15, Klaus Schneider <klaus at cs.arizona.edu
>>> > <mailto:klaus at cs.arizona.edu>> a écrit :
>>> >
>>> >
>>> >
>>> >     On 8/5/19 1:33 PM, Ahmed BENMOUSSA wrote:
>>> >      > Hello everyone,
>>> >      >
>>> >      > I am sending you to ask about the NDN stack.
>>> >      > In some papers, researchers include a "/Transport/" layer to
>>> the NDN
>>> >      > stack as follows:
>>> >      > ======================
>>> >      > \ *Application */
>>> >      >   +--------------------------------------+
>>> >      >    \ *Transport */
>>> >      >     +----------------------------------+
>>> >      >       \ *NDN */
>>> >      >        +-----------------------------+
>>> >      >       / *Link-layer*      \
>>> >      >     +----------------------------------+
>>> >      >    / *Physical* \
>>> >      >    =====================
>>> >      >
>>> >      > Other researches don't include it in their papers.
>>> >      >
>>> >      > My question is: What is the role of the "/Transport/" layer in
>>> >     this case?
>>> >      > Knowing that the "Link-layer" includes any communication
>>> protocol
>>> >     that
>>> >      > NDN could use as a tunnel to send and receive traffic, why a
>>> >      > "/Transport/" layer is added?
>>> >
>>> >     Also, I think this question can be answered with pure IP network
>>> logic:
>>> >     Tunnels can only provide point-to-point reliability between NDN
>>> nodes.
>>> >     But many applications need end-to-end reliability. Hence, the need
>>> >     for a
>>> >     transport layer (or similar functionality, i.e. ARQ, at the
>>> consumer).
>>> >
>>> >     Best regards,
>>> >     Klaus
>>> >
>>> >
>>> >      >
>>> >      > Is this layer added to support future NDN deployment? (When
>>> >     native NDN
>>> >      > communications are used instead of IP overlays). Or does it have
>>> >     other
>>> >      > roles?
>>> >      >
>>> >      > What NDN stack should I consider in my papers and presentations?
>>> >     (with
>>> >      > or without the Transport layer).
>>> >      >
>>> >      > Thank you in advance.
>>> >      >
>>> >      > Kind regards,
>>> >      > Ahmed. B.
>>> >      >
>>> >      >
>>> >      > _______________________________________________
>>> >      > 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
>>> >      >
>>> >
>>> >
>>> > _______________________________________________
>>> > Ndn-interest mailing list
>>> > 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/20190806/e6f3c511/attachment.html>


More information about the Ndn-interest mailing list