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

2. 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.

3. 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.

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

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

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

18. 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

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

21. 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

22. Prefix Hijack (Data Delivery Ratio)
May 2011
NDN Retreat

23. Prefix Hijack (Data Retrieval Time)
May 2011
NDN Retreat

24. Link Failure (Packet Loss Rate)
May 2011
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.
May 2011
NDN Retreat

26. Congestion (Flow Throughput)
May 2011
NDN Retreat

27. Congestion (Link Utilization)
May 2011
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.
May 2011
NDN Retreat