Robust Packet Delivery in Named Data Networking Beichuan Zhang May 2011 NDN Retreat

Communication Models Conversation Content Retrieval 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.

The Trend Contents matter more Addresses matter less 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.

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

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.

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.

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.

NDN node

NDN packet processing May 2011 NDN Retreat

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.

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?

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.

Transport No need for flow control In-network congestion 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. Retx doesn’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.

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) May 2011 NDN Retreat

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) we want to convey the point that it is impossible to make a real routing system to match "perfect switching", due to  - every router (by all different parties) injects input into the system - there are physical limitations between convergence delay and scalability May 2011 NDN Retreat

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’t have to be perfect. E.g., prefix hijack, link failure, congestion. May 2011 NDN Retreat

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. May 2011 NDN Retreat

Ranking Faces The factors The specific design we simulated 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. May 2011 NDN Retreat

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. May 2011 NDN Retreat

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 May 2011 NDN Retreat

Simulation Setup Simulator Topologies: Abilene and Sprint 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 May 2011 NDN Retreat

Prefix Hijack (Data Delivery Ratio) May 2011 NDN Retreat

Prefix Hijack (Data Retrieval Time) May 2011 NDN Retreat

Link Failure (Packet Loss Rate) May 2011 NDN Retreat

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. May 2011 NDN Retreat

Congestion (Flow Throughput) May 2011 NDN Retreat

Congestion (Link Utilization) May 2011 NDN Retreat

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. May 2011 NDN Retreat