CoNEXT'13 Student workshop: Best Paper Session

ndn||mem an Architecture to Alleviate the Memory Bottleneck for Named Data Networking

Authors: M. Rezazad,Y.C. Tay

Presenter: M. Rezazad

This paper proposes a new architecture for NDN to alleviate the performance bottleneck caused by the high usage of memory in NDN architecture. 

In NDN, the name represents the content instead of the location of the data source, and the application basically follows the publish/subscribe paradigm. The contents are cached in the routers. In this architecture, the main concern is that since high speed memory is not affordable yet, the content searching may slow down the overall system performance. 

The authors propose four ideas to reduce the problem. First, parallel search in FIB and PIT. Second, under the assumption that FIB is a big slow memory, the routing information of the first data chunks can be cached in FIBcache for the later interests to use. Third, under the assumption that data chunks are likely to physically reside on the same node, if the previous chunk is not found in the CS, the following interests can skip the CS search step. Finally, the authors change the content caching policy (CCNdn) to only caching part of a file in a file at each router along the path. Since the head of a file is assumed more popular than the tail, it is suggested the head is saved at routers closer to the requester.

The new architecture is evaluated through simulations and the results show that the proposed architecture is more scalable in terms of memory search compared to the current NDN architectures.

Q: How do you debug NDN network?

A: This is an open issue. Currently there is no device for that.

Q: can we assume the content is in one server? (replication of data) what if there are multiple servers? How do we decide number of hops? 

A: It is the routing algorithm problem. In NDN it is assumed the packet will be forwarded to the shortest path resource. After the search the path can be used by another interest. 

Q: do you support content replication at all?

A: content replication is for CDN. 

Don't Trust Traceroute (Completely) 

Authors: Pietro Marchetta, Valerio Persico, Ethan Katz-Bassett, Antonio Pescapè

Presenter: P. Marchetta

The main message of this paper is not to trust Traceroute. The presenter first introduced the basic concept of Traceroute. Traceroute currently has many limitations, such as its capability of detecting anonymous, hidden routers, and also its probing overhead. In this paper, the authors focuses on the problem at IP level view.

The major problem is that Traceroute discovers "interfaces" rather than "routers". Because of that, in practive Traceroute may detect false path changes. The presenter showed an example where Traceroute reports a path change at second hop while it turns out only the interface is changed on the same router. In the evaluation using 721k paths, it is found that 32% of the paths have not changed at the IP level while Traceroute reported path changes.

Another problem is the load-balanced path over estimation. Routers may split the traffic in different paths. That is, multiple IP level paths may be identified by Traceroute even though the forwarding path is the same.

Q: Are you building on top of Traceroute?