Robust Packet Delivery in Named Data Networking

1. Robust Packet Delivery in Named Data Networking Beichuan Zhang NDN Retreat

2. Communication Models • Conversation • Point-to-point, emphasize the e2e paths or channels. • Packets carrying addresses simply flow in the channel. • IP adopts the same communication model as the telephone service, just the solution is different. • Content Retrieval • Request content from network services. • Emphasize on the content of the packet, not the location of the content or the channel. • Both can probably support all possible services, given enough efforts. The question is which one fits application needs better.

3. The Trend • Contents matter more • Web caching • Multicast, video conferencing • Subscription/publication services • Security and privacy • Addresses matter less • Limited in supply. • Some are non-reachable, e.g., private v4, or isolated v6. • More and more are moving. • Quite a few proposals to make network content centric rather than location centric.

4. Named Data Networking (NDN) • Previously known as Content Centric Networking (CCN). • Currently in its very early stage, lots of questions, challenges, and research opportunities. • Key idea: • Give each packet a unique name. • Packets are routed and forwarded based on names. • Other ideas: • Routers cache packets • All communication is receiver-driven, ie. Interest precedes Data. • Evidentiary security

5. Name the data • Hierarchical names • To facilitate aggregation, management, and discovery. • Routers understand that there are different components in the name, but do not care about the actual meaning of each component. • Applications manage their naming conventions and discovery mechanisms. • E.g., the scope of a name; generate dynamic content for certain names.

6. What about addresses? • Addresses are limited to local links • No need for addresses that are globally unique, globally reachable, and abundant in supply. • The new universal interconnection layer is “named data”. • IP eventually becomes a link layer protocol.

7. Receiver-driven data retrieval • Consumer sends an interest carrying the name of the data that it wants to receive. • Routers forwards the interest towards the producer, and remembers the incoming interface of the interest. • The producer sends the data back. The data takes the exact reverse path of the interest to reach the consumer. • Data consumes Interests on the way back. • Routers also cache the data as it arrives.

8. NDN node

9. NDN packet processing NDN Retreat

10. Interest Forwarding • NDN doesn’t loop. • Each Interest has a random number, nonce, to prevent looping. • Data follows Interest’s trail, so Data doesn’t loop either. • Thus NDN can use multiple paths better than IP. • the extreme is to flood an interest, and data will come back. IP would have to flood the data too. • Lots of choices in where to forward a particular interest: the forwarding strategy. • More details and evaluation later.

11. Routing • Server apps register their name prefixes with the local router. • Routers announce name prefixes into the routing system. • Conventional routing protocol can be used to compute the paths to each name prefixes. • New routing protocols are also possible. • How to scale the routing table?

12. Caching • Universal caching by routers helps in several different scenarios • multicast • asynchronous retrieval • Congestion control • Mobility support • How much memory/disk does it take? • Routers already use memory for buffering, but not caching since no way to identify the content. • With named data, change MRU to LRU replacement policy. • Possible add-on services by ISPs: selling extra cache for specific contents.

13. Transport • No need for flow control • Interest does that. • In-network congestion control • By controlling the number of pending interests to control the data rate. • Quicker local recovery due to cache. Retxdoesn’t have to start all over again from the producer. • No transport protocol in the traditional sense. • The apps need naming convention, name discovery, and maybe end-to-end reliability.

14. Robust Packet Delivery • The ultimate goal of routing and forwarding is to deliver packets. • The ideal is what Paul Baran called “perfect switching”: be able to deliver packets in the presence of faults as long as the destination is still reachable. • This study: • Evaluate NDN vs. IP • Explore some design choices in NDN forwarding strategies. • without considering the benefits and impact of caching (next step) NDN Retreat

15. Data Delivery in IP • Routing plane computes the best paths • data plane (packet forwarding) simply follows the paths. • Achieving perfect switching requires perfect routing – reality is far from it, e.g., • Prefix hijack (routing is fooled) • Link failure (routing convergence is slow) • Congestion (routing is not aware of the problem) NDN Retreat

16. Data Delivery in NDN • Routing plane stays the same for now • but data plane has state and in charge now. • Monitor the performance. • Detect problems at the data plane quickly • Explore multiple alternative paths • Routing plane is now a helper, i.e., it’s useful but doesn’thave to be perfect. • E.g., prefix hijack, link failure, congestion. NDN Retreat

17. Overview of Forwarding Strategy • Forwarding strategy is to determine which face to use to forward an interest. • Basic process: • Faces are ranked • In general, try higher ranked face(s) first • If data return within a reasonable time, update RTT. • Otherwise, try next face(s). • Different strategies may make different choices. • Ranking is dynamically adjusted. • Details are work in progress. NDN Retreat

18. Ranking Faces • The factors • Routing provides the initial and basic information. • Forwarding preference, e.g., • inter-AS peer relationship, etc. • Performance metrics • Throughput, loss rate, RTT, etc. • The specific design we simulated • Faces are labeled Green (working), Yellow (may work), Red (not working), based on whether data come back. • Within each class, ordered by routing preference. NDN Retreat

19. Choosing Faces • When no faults, i.e., data return as expected • Use the highest ranked face, but periodically probe other faces by sending interests over. • Or, spread the interests over multiple faces. • When data don’t come back after expected RTT • E.g., hijack, link failure, congestion, etc. • NDN can keep trying different faces without worrying about loops. • What we simulated: • Round-robin based on the ranking • Retransmission plus round-robin • Flooding • Each face also enforce an interest limit • It is available for forwarding only if there’s room for more interests. NDN Retreat

20. Interest Return • When a node cannot satisfy an interest, it returns the interest to the previous hop • data are ACKs, while returned interests are NACKs. • With error code to indicate the reason • Pro:the downstream node learns the problem quicker and more explicitly. • RTT-based timeout is conservative to avoid false alarms • Con: an extra mechanism • Ongoing work: comparing w/ and w/o interest return under proactive multipath forwarding to quantify the benefit from Interest NACK NDN Retreat

21. Simulation Setup • Simulator • Implemented basic NDN forwarding functionality and strategies in QualNet. • Plan to move to ns-3 with full NDN/CCNx functionality. • Topologies: Abilene and Sprint • Routing protocol: OSPF • Scenarios: hijack, link failure, congestion • Comparison: IP vs. NDN NDN Retreat

22. Prefix Hijack (Data Delivery Ratio) NDN Retreat

23. Prefix Hijack (Data Retrieval Time) NDN Retreat

24. Link Failure (Packet Loss Rate) NDN Retreat

25. Congestion Setup • Two file downloading sessions: 1-6 and 2-7 • RTT (1-6) = 104/106 ms, RTT(2-7) = 202/204 ms. • Buffer size = bw*rtt • To show that NDN is able to use multipath on-demand. NDN Retreat

26. Congestion (Flow Throughput) NDN Retreat

27. Congestion (Link Utilization) NDN Retreat

28. Conclusion and Ongoing Work • Data delivery in NDN is more robust than IP. • able to observe delivery performance and adapt. • Closer look at various design issues, including interest return. • Move simulation to ns-3 and add more functionality. • Further investigation in some scenarios. • e.g., congestion control, DDoS. NDN Retreat