NDN Retreat 1

Robust Packet Delivery in Named Data Networking

Beichuan Zhang

May 2011

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

NDN Retreat 9

NDN packet processing

May 2011

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

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

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

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

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

May 2011

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)

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