ndn||mem an Architecture to Alleviate the Memory Bottleneck for Named Data Networking
Authors: M. Rezazad,Y.C. Tay
Authors: M. Rezazad,Y.C. Tay
Presenter: M. Rezazad
New memory architecture for NDN (Name Data Networking), which is one of the candidate for future internet architectures. The presenter first gave brief overview of the NDN including main concepts such as name for content rather than location of the content, publish/subscribe phenomena and caching content in the routers.
The main goal of this work is to improve memory search delay as it is one of the major concerns of the current NDN architecture. The authors propose four stage strategies under their new memory architecture.
- Parallel search - in FIB (Forwarding Interest Base) and PIT (Pending Interest Table) tables
- FIBcache - Routing information of the interest of the first data chunks can be used for the rest of the chunks by caching them in FIB and PIT.
- Bypass CS - If data n is found in the CS table, it is likely data n+1 can be found there. Therefore, it is possible to bypass CS by using hop distance
- Content Caching Policy (CCndn) - Cache only part of a file in a router by segmenting file in pieces and distribute pieces along the path.
The authors have evaluated this through simulations and showed that the proposed architecture can tolerate more traffic due to the time saved during the memory search compared to the standard NDN architectures.
Q: Is it possible to apply Traceroute in NDN context?
A: In NDN, location is not important, I can’t see why the finding location is important and the authors explains basics about NDN.
Q: Related to the same question, How do you debug NDN network?
A: This is not a finished research I would say. Parc institute adding some algorithms to do similar kind of analysis.
Q: A question about replication of content in routers in NDN. Do we need to research all routers to get one content?
A: It is a problem of the routing algorithms, and the author explained how NDN routing works. CDN makes content localised and it is different from content caching in NDN.
Authors: Pietro Marchetta, Valerio Persico, Ethan Katz-Bassett, Antonio Pescapè
Presenter: P. Marchetta
The message of this paper is not to trust Traceroute too much. The presenter gave an introduction to the trace route protocol and its practical utility followed by its limitations and mainly focused on limitations on IP level-view. Traceroute is designed in such a way that it detects interfaces rather than actual routers, which creates two main limitations.
- False path changes - detect interface changes as path changes
This scenario has been evaluated using 721k paths collected by 4 PlanetLab nodes for 2 days. The most interesting finding was that 32% of the paths changed at the IP level.
- Load-balanced path over estimation
Routers usually split the traffic in different paths. Sometimes, even though the forwarding path is the same, Traceroute suggests multiple forwarding packets. From the same data set, the authors show that 14% of the routes with multiple IP level paths identified by the Traceroute turned out to be unique paths.Then the presenter explained how this is possible. Tracroute may report outgoing interface according to the RFC.
Finally, the presenter conclude with set of future work highlighting that this is early stage research. Some future work are What is the actual magnitude of the phenomenon?, analysing wider data set, revisiting stability, etc..
Q: Your analysis are based on alias level - How do you mange error?
We had limitations of coverage, accuracy and also it was not possible to apply to a large scale. We applied the used techniques several times to remove as much as false positives. However, still there might be some errors.
Q:xx
A: Explain about the behaviour of false multiple path detection.
Q: Who are the primary stake holders? Are you building on top of Traceroute?
A: xx
No comments:
Post a Comment