[Ndn-interest] NDN Stack

[WENTAO SHANG]

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/0b9c72bc/attachment-0001.html>