## 9 Discussion  
In a generic ICN, the flooding mechanism, forwarding an Interest PDU through all available interfaces except for the ingress interface, is the only defined place specification mechanism. This method is unable to determine what related Parts are necessary or where they are located. In other words, ICN defines a figure \(F\), but it gives no clue as to how to find Parts that are 'close'to that initial \(F\). This means that SF only updates the location of the one particular ICN name in the Interest PDU that caused the initial flooding. A related downstream Data PDU would enable the interface for future use, but it assumes that subsequent related Data PDUs are stored in one of the nodes that are connected by the newly enabled interface. Specifically, the naming scheme does not have any topological properties. Figure 9: Timed out Interests to satisfy consumer Interests ratio for forwarding strategies  
This feature of the Data PDU is also shared by the MAP-Me-IU. The location of future ICN name chunks are assumed to be locatable using the interface that leads to the mobile producer. This is an assumption that can be easily wrong when a producer is moving fast. This assumption gets worse when the producer is pushing content while moving. In the mobility framework used, the consumer begins to ask for an ICN name 20 s after the producer has begun to push content, meaning that a currently enabled interface in the FIB might not correspond to the actual Part that the consumer has requested. The results of SF MM are consistent with this interpretation, as SF MM (Question 2 = \(\bigtriangleup\)) obtains overall worse results when compared with SF (Question 2 = \(\bigcirc\)). As the speed of the producer node increases, related Parts are divided into smaller intervals on the edge CR CSs, with bigger gaps between two complete intervals on any given CS. The results worsen when the node reaches a speed that not only makes the related Part intervals smaller, but has the intervals be on nodes that are further apart in the GN. This in turn causes more flooding because the network has no way of locating the Parts in advance. As the results in the previous section have shown, being able to ask _where_ a particular piece of an ICN name, which was named a Part (Question 3 = \(\bigcirc\)), is located, automatically offers us results that greatly improve delay, goodput and the Interest timeout to satisfied consumer Interest ratio. This improvement is maintained even if the ground \(G\) is of limited scope (Question 4 = \(\times\)). The limited scope of the ground \(G\) is not as problematic in the mobility framework due to the fact that the wired network creates a connected tree where one interface has only one possible destination. Due to the properties of a tree graph, like the one used in the GN, there is negligible difference between keeping the 3N name of an edge node updated for a Part interval and keeping the interface that leads to the edge node updated. If the requirements of one's network can be satisfied with the delay and goodput levels shown in the results, then enabling a larger scope for ground \(G\) seems unnecessary. This is a point worth considering, particularly when considering the number of modifications required to satisfy Question 4. If one wishes to further improve delay and goodput, the previous results show a significant improvement when the naming scheme defines a ground \(G\) of larger scope that is also a metric space (Question 4 = \(\bigcirc\)). It is important to remember that in the mobility framework, all buffering was disabled and PDUs had to be forwarded in a reactive manner. This means that the improvements observed come only from PDUs being forwarded using updated 3N name (ground \(G\)) information. Equally important is that downstream Data PDUs generally reach the consumer because the 3 NA NNPT keeps the list of the latest 3N name being used by nodes. This particular feature accounts for the difference seen between SF MM PR and SF MM PR 3N.