Why Should We Route On Trees?

In this thesis we decided to create a routing scheme based on trees. Trees are good structure to use for routing, as they do not have loops and they can be used easily to forward messages in multicast. These are good properties since ICN is intrinsically multicast. When we have multiple sources for the same content, or when we have multiple subscribers for the same event notification service, there are points in the network where packets need to be duplicated and sent to multiple destinations. This process can easily generate loops.

CCN uses tables called Pending Interest Tables (PITs) at each node. PITs are used to collect soft state related to the interests forwarded by the router but not yet satisfied (and therefore removed) by a corresponding data packet. The PITs have three main purposes:

1. The state in the PITs is used to route the data packets back to the the user that sent the interest.

2. PITs are used to aggregate interests for the same content, and therefore reduce traffic in the network.

3. PITs can stop loops in the interests forwarding process.

In this section we present some scenarios where the PITs fail to detect loops and they lead to a misbehavior of the network. The most recent versions of

49 3.3 Routing Scheme

CCN (since version 1.0) use a different implementation of the PITs. NDN still uses a PIT similar to the one proposed in the initial implementation of CCN. We therefore compare the behaviors of NDN and the older version of CCN, both indicated with CCN 0.x, with the new CCN, indicated with CCN 1.x

In CCN 0.x, each interest has a name associated with a nonce that uniquely identifies that particular interest. The PIT stores the nonce with the name, in order to avoid to re-send the same interest in case of loops. CCN 1.x does not use nonces. Instead, an interest has a hops-to-live counter that limits the interest transmission. At each hop, the hops-to-live counter is decreased and, when it reaches 0, the interest is dropped. This approach does not prevent loops, it simply mitigates the problems induced by loops.

a

b

c

d

e

f

interest

Figure 3.1. Scenario 1: loop path

In Figure 3.1 we show a simple scenario where an interest, represented with a blue arrow, falls into a loop. The interest goes from node a to node b, then b decides to forward the interest along to c, and node b also records the interest in its PIT. In the case of CCN 0.x, this PIT entry contains the name of the interest and its nonce. When b receives the interest for the second time, from node f , it detects a loop, because the interest has a nonce that is already in the PIT. In this case node b discards the interest. However, if the time required for the interest to go through the loop to reach node b for the second time is higher than the timeout set in PIT entry at node b, then the interest may loop. The loop is represented in the figure with dashed arrows. In CCN 1.x, node b is unable to detect the loop, so the interest loops but is eventually discarded as soon as the hops-to-live counter goes to zero. Although this version has the advantage of eventually cutting loops, it may also generate useless traffic, especially if the initial hops-to-live counter is high. On the other hand, if the hops-to-live counter is too low, then the interest may never reach any of its destinations and the user may not receive the requested content.

50 3.3 Routing Scheme

multiple paths, as described in Figure 3.2 and Figure 3.3. This happens, for example, when an interest is used as a notification packet. In Figure 3.2, node

b sends the same interest to nodes c and f , and the two copies of the interest are propagated to node d. In CCN 0.x node d detects the duplicate interest, since it receives two interests with the same nonce form two different interfaces. What happens in this case is that the second interest, say the one from node

f, is discarded and node d keeps track only of the interest coming from node

c. The data packet related to the interest goes back to node a using the path

d, c, b. This creates a dangling PIT entry at node f that will eventually timeout and therefore will eventually discard. In the case of CCN 1.x, since node d does not detect any duplicate delivery of the same interest, node d will aggregate the two interests from nodes c and f . Node d then forwards the data packet to both

cand f , so node b will receive duplicated data (represented with a dashed line).

a

b

c

d

e

f

Figure 3.2. Scenario 2: duplicated interest

Ultimately, node b forwards only one copy of the data to a, since the first for- ward to a also removes the corresponding PIT entry. In this scenario everything works correctly from the application viewpoint, even if in the case of CCN 1.x we have some extra traffic.

However, the same scenario may create some problems, as described in Fig- ure 3.3. As in the previous case, node b sends the same interest to both c and

f, and d receives first the interest from c and later the one from f . In CCN 0.x node d discards the interest from f , while in CCN 1.x the two interests get ag- gregated. At this point, node g sends another interests with the same name, indicated in the picture with a green arrow, to node f . Node f has an entry for that interest in its PIT, so the interests is aggregated. This happen in both CCN 0.x and CCN 1.x. However, in CCN 0.x d forwards the data packet only to node c, because the interest from f was discarded. So, in this case, node g never receives the requested data.

51 3.3 Routing Scheme

This does not happen in CCN 1.x, because node d aggregates the interests that are coming from c and f , without discarding them, and node g receives the required data packet. The data packets sent by CCN 1.x are represented with dashed arrows in Figure 3.3. Also in this case CCN 1.x generates useless traffic, since the data packet from node f to b is a duplicated packet.

a

b

c

d

e

f

g

Figure 3.3. Scenario 3: duplicated interest

In a network that is multicast in nature, it is not easy to avoid loops. PITs are generally good to detect loops, but they may fail in some cases. When an error in a PIT occurs, some users may not receive the data that they ask for. Adding the hop counter solves the problems of the PIT, but it introduces traffic overhead.

Our design avoids all these problems, by construction, using trees as a basis for routing. This way packets will never fall into loops, whether they are unicast, anycast, or multicast packets. And furthermore, this design does not require any in-network state thanks to locators.

Other architectures such as PURSUIT propose to use trees to forward pack- ets in what amounts to a multicast group. In particular, thanks to the LIPSIN construction, the PURSUIT architecture can efficiently represent and forward packets along a tree connecting a producer to all consumers[48]. A LIPSIN tree is represented as a set of edges represented with a compact Bloom filter. The notion of a LIPSIN tree is limited to a local domain, where it is reasonable to assume knowledge of all links.

Although based on trees, the PURSUIT architecture and its routing scheme differ quite substantially from TagNet. PURSUIT uses a DHT overlay to locate the content, and then uses a “topology layer” to build and return a LIPSIN tree to

52 3.3 Routing Scheme

distribute content. Thus PURSUIT is more akin to a connection-oriented network than a datagram network, in the sense that an all-knowledgeable and conceptu- ally centralized topology layer must set up a LIPSIN tree before that the tree can be used to transmit content. By contrast, in TagNet we use a set of base trees that are not specific for any producer, and then we forward each packet along one of those trees making hop-by-hop forwarding decisions based on the packet content (descriptor).

It is worth noticing that, since we do not need to keep any in-network state for request packets, we can completely remove the PITs from our architecture. This reduces complexity but also eliminates the aggregation of concurrent re- quests, and therefore may increase traffic. However, our architecture still allows for in-network caching, which can play a similar role as the PITs for interest ag- gregation. This is because, as soon as a request is satisfied along a path, all the following requests that cross that path can be satisfied by the cached content. Therefore we believe that our architecture would not introduce much additional traffic, as compared with CCN, even without the PITs. Our intuition is also con- firmed by a study conducted by Kazi et al. that shows the dynamics that relate the behavior of the caches and the PITs[49]. In particular, the study shows that, under normal traffic conditions, interest aggregation in the PITs reduces traffic only marginally, and that the majority of traffic reduction is due to cached con- tent. Interest aggregation in the PITs becomes more effective only in the case of heavy loads, when cached content is too quickly overwritten by new content.