[Ndn-interest] Issues in routing

[Klaus Schneider]

> The nfd connection states that after installing NFD in a client machine, 
>> we can specify the IP address and port number of the remote NFD, so that 
>> NDN packets get encapsulated into UDP or TCP packets and sent to the 
>> remote NFD. e.g. nfdc create udp4://192.0.2.1:6363 

You are talking about running NDN over IP tunnels (here, UDP tunnels). 
However, these tunnels only exist for point-to-point communication 
between routers to make NDN run over IP networks. They could easily be 
replaced by an Ethernet face (if there was a direct Layer 2 connection 
between two routers).

When using the word connection in your earlier sense ("and the 
connections [a router] holds", "take care the connections of the nodes") 
I assumed you are talking about a transport layer connection as it 
exists in TCP between client and server.

However, this transport layer connection does not exist in NDN. A router 
does not maintain any connection state, thus nothing dramatic happens to 
the packet flow after a router goes down. You will lose a number of 
Interests/Data packets that would have gone through the router, but 
these can quickly be retransmitted, and will find a different path to 
the repository (if it exists).

> when a 
>> new ndn node wants to enter in an existing network and establish a 
>> connection with a node of the network, it does the above thing, isn't 
>> it?

This is different from the idea of a transport-layer connection, as 
described above. If your node could have a wired Ethernet connection to 
an NDN router, this step wouldn't be necessary. You could just send 
Interests to that router without needing an IP address.

Moreover, I don't think it's related to routers going down, unless you 
are talking about your access router. In this case, you will (of course) 
need to re-establish the tunnel to the access router after it comes back up.



Best regards,
Klaus




On 11/19/18 2:15 PM, Tanusree Chatterjee wrote:
> Hello Klaus,
> 
> Thank you. It cleared my doubts to some extent. But, you said that there 
> is no notion of connection in NDN and I did not understand what does it 
> exactly mean.
> The nfd connection states that after installing NFD in a client machine, 
> we can specify the IP address and port number of the remote NFD, so that 
> NDN packets get encapsulated into UDP or TCP packets and sent to the 
> remote NFD. e.g. nfdc create udp4://192.0.2.1:6363 
> <http://192.0.2.1:6363/>  states the client machine wants to establish a 
> connection with 192.0.2.1:6363 <http://192.0.2.1:6363/>. Also as 
> Junaxio's explained in my last email answer that NDN-FCH service tells 
> us the IP of the routers near by. However, here I am a bit confused why 
> there is no notion of a connection. As my previous question was when a 
> new ndn node wants to enter in an existing network and establish a 
> connection with a node of the network, it does the above thing, isn't 
> it? Please tell me if I understood anything wrong.
> 
> Thanks & Regards,
> Tanusree Chatterjee
> 
> On Nov 19, 2018 11:08 PM, "Klaus Schneider" <klaus at cs.arizona.edu 
> <mailto:klaus at cs.arizona.edu>> wrote:
> 
>     Hey Tanusree,
> 
>     I think it's useful to distinguish between 3 logical entities:
> 
>     1. Router -- forwards packets towards a storage location
>     2. Content Store -- a temporary storage location (can be cleared at
>     any time)
>     3. Content Repository -- a permanent storage location (in the same
>     sense as today's web servers are "permanent")
> 
>     These can all be on the same machine or on a different machine. For
>     example, a core NDN router will probably have a content store, but
>     not a content repository.
> 
>     Now to answer your questions:
> 
>         So, if a router is down for some reason, what about the data it
> 
>             stores in its CS and the connections it hold?
> 
> 
>     Well, the content store will be unreachable. There is usually no
>     notion of a "connection" in NDN, so other routers should be able to
>     fetch the data from somewhere else.
> 
>         If the router is
> 
>             temporarily down, it can resume to its normal operations
>             sometime later
> 
> 
>     Sure. Why not?
> 
>         But if the router is permanently down and there are several data
> 
>             it produce and there are no more copies of all the data.
> 
> 
>     That only matters if the last content repository is down. In this
>     case the data might become unavailable, if all the content stores
>     have cleared the data as well (which they are free to do).
> 
>     NDN does not have the goal to permanently replicate every content
>     piece inside the network. The content provider is still responsible
>     for keeping their content repository up and running, and likely
>     wants to provide some redundancy here.
> 
>     NDN, however, can help with the scalability: it reduces the load on
>     the content repository when its content objects become more popular.
> 
> 
>     Best regards,
>     Klaus
> 
> 
> 
>     On 11/19/18 2:32 AM, Tanusree Chatterjee wrote:
> 
>         Hello all,
> 
>         In NDN the routers are the busiest and most responsible entity
>         in the network. So, if a router is down for some reason, what
>         about the data it stores in its CS and the connections it hold?
>         If the router is temporarily down, it can resume to its normal
>         operations sometime later.  But if the router is permanently
>         down and there are several data it produce and there are no more
>         copies of all the data. Can there be any network administrator
>         which can have the copies of the data of a router when it is
>         down? If it is a high connectivity node, can network
>         administrator can play a vital roll to take care the connections
>         of the nodes?
> 
>         -- Thanks & Regards,
>         Tanusree Chatterjee
> 
> 
>         _______________________________________________
>         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
>         <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>
>