NFD

Feature #4973

Updated by Teng Liang over 4 years ago

The current self-learning implementation of #4279 allows NFDs to learn FIB entries through Prefix Announcement piggybacked on Data replying to discovery Interest. The learned next hop is where Data sent back, so the next hop will be a multicast Face by default. 

 We tested the performance of UDP multicast and unicast Face in WiFi AP-station mode. The testing topology consisted of two laptops connecting to one Openwrt router.NDN catchunks and putchunks were used to download and publish data. The goodput of unicast is about **5x** as good as the multicast. The detailed statistics is listed in the end. Therefore, the multicast/Unicast face switching is important.  

 To implement Face switching, our existing effort was to extend the concept of *Face* to [*Face-EndpointId*](#4282). This approach will leave *EndpointId* in table, management and forwarder modules, but these modules in NDN should not deal with *EndpointId*. 

 To avoid Face extension with EndpointId, this design allows This task is to allow forwarding strategy to create unicast Face, so it can announce routes towards the unicast Face on receiving Data packet from multicast Face. The implementation design has 7 steps described below. 

 to archive Face switching.  

 **Step 1** one** 
 Pass face system to forwarder, so forwarder can use it to create face for strategies. 

 **Step 2** Two** 
 To create a face, face system has to know which protocol factory should be used, and required parameters, including local uri, remote uri and parameters related to face.  

 * To get *ProtocolFactory*, one way is to add *ProtocolFactory Id* to *Transport*, then *FaceSystem* is able to get *ProtocolFactory* from *Face*->*Transport*->*ProtocolFactory Id* 
 * The *Remote Uri* can be attached to Data by the sender. This should only happen to discovery Interest sent to multicast Face, and this should not be a common case. 
 
 **Step 3**: three**: strategy requests unicast face creation 
 
 ``` 
 void 
 SelfLearningStrategy::afterReceiveData(const shared_ptr<pit::Entry>& pitEntry, const FaceEndpoint& ingress, const Data& data) 
 { 
      // 1. check if the unicast face needs to be created 
      // 2, prolong PIT entry lifetime, so that PIT entry still exists when face is created 
      // 3. request face creation  
      this->createUnicastFaceOnData(pitEntry, data); 
 } 
 ``` 

 **Step 4**: four**: *Forwarder*    forwards face creation request to *FaceSystem* 

 ``` 
 void 
 Forwarder::createUnicastFaceOnData(const PitEntry& pitEntry, const Data& data) 
 { 
     faceSystem.createUnicastFaceOnData(data, [] (const Face& face) { 
         // Step 5 STEP FIVE 

         // 1. if PIT entry has been deleted, return 
         // 2. find effective strategy for pitEntry.getName() 
         // 3. strategy.afterUnicastFaceCreation(pitEntry, face) 
     }); 
 } 
 ``` 
 
 **Step 5**: five**: FaceSystem asks ProtocolFactory to create face 

 ``` 
 void 
 FaceSystem::createUnicastFaceOnData(const Data& data, function<void(const Face& face)> callback) 
 { 
     // 1. extract packet tag and determine which ProtocolFactory owns the multicast face 
     // 2. pass remote endpoint information to the ProtocolFactory, which then creates the face 
     ProtocolFactory.createFace(remoteEndpoint, callback); 
 } 
 ``` 
 
 **Step 6** six** is in the callback function in the step three. 

 **Step 7**: seven**: use the newly created face in the callback function 

 ``` 
 void 
 SelfLearningStrategy::afterUnicastFaceCreation(const PitEntry& pitEntry, const Face& face) 
 { 
   // add route towards the face 
 } 

 class Strategy { 
 public: 
     void afterUnicastFaceCreation(const PitEntry& pitEntry, const Face& face); 

 protected: 
     void createUnicastFaceOnData(const PitEntry& pitEntry, const Data& data); 
 }; 
 ``` 

 ## NDN catchunks/putchanks for consumer---WiFi AP---producer 
 ### Unicast: 

 All segments have been received. 
 Time elapsed: 6.83123 seconds 
 Segments received: 1317 
 Transferred size: 1447.75 kB 
 Goodput: 1.695452 Mbit/s 
 Congestion marks: 0 (caused 0 window decreases) 
 Timeouts: 23 (caused 16 window decreases) 
 Retransmitted segments: 23 (1.71642%), skipped: 0 
 RTT min/avg/max = 8.058/71.200/421.579 ms 

 ### Multicast: 

 All segments have been received. 
 Time elapsed: 33.6946 seconds 
 Segments received: 1317 
 Transferred size: 1447.75 kB 
 Goodput: 343.734634 kbit/s 
 Congestion marks: 0 (caused 0 window decreases) 
 Timeouts: 553 (caused 191 window decreases) 
 Retransmitted segments: 550 (29.459%), skipped: 3 
 RTT min/avg/max = 16.970/88.583/333.864 ms 

Back