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. multicast Interests. The learned next hop is where Data sent back, so the next hop current implementation works poorly with WiFi infrastructure, because a consumer connects to a WiFi AP will be always learn routes towards a multicast Face by default. We tested the performance of UDP Face, and multicast and unicast Face performs poorly in WiFi AP-station mode. The testing topology consisted of two laptops connecting WiFi. To solve this issue, self-learning should be able to one Openwrt router.NDN catchunks and putchunks were used switch from multicast to download and publish data. The goodput of unicast while learning routes. This post 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 discuss a reasonable implementation design for this feature. To implement summarize existing designs: * Refactoring Face switching, our existing effort was to extend be identified from *FaceId* to *FaceId+EndpointId* * An overkill approach to the concept described issue with a lot of *Face* workload and requiring the forwarding plane to [*Face-EndpointId*](#4282). This approach will leave handle EndpointId everywhere * Build another self-learning module inside Face to handle *EndpointId* in table, management * Still a lot of changes since Face needs to maintain separate PIT and forwarder modules, but these modules in NDN should not deal FIB, and handle the verification of prefix announcement (or sync with *EndpointId*. rib io thread) This task is * Send Data to allow forwarding strategy unicast face to create reply Interest from multicast face + learning routes to unicast face * no Face refactoring or putting SL in Face, so it can announce routes towards minimizing workload The tasks for the third design include: 1. Creating unicast Face to archive on receiving Interests from multicast Face switching. **Step one** Pass face system to forwarder, - Currently, only UDP Face has this feature, so forwarder self-learning can use it to create prefer UDP multicast face for strategies. content discovery **Step Two** To create a face, face system has 2. Sending Data to know which protocol factory should be used, unicast Face instead of multicast Face - EndpointId is still needed in PIT entry in-record, so strategy can find the corresponding unicast Face with this EndpointId and required parameters, including local uri, remote uri and parameters related to face. * To get *ProtocolFactory*, one erase the in-record after sending Data. - One way is to add *ProtocolFactory Id* attach EndpointId to *Transport*, then *FaceSystem* is able Interests (only to get *ProtocolFactory* from *Face*->*Transport*->*ProtocolFactory Id* * The *Remote Uri* can be attached to Data by `discovery` Interests). To find the sender. This should only happen to discovery Interest sent to multicast correct unicast Face, strategy can enumerate all faces and this compare EndpointId with their remote Uri. 3. On receiving Data from unicast Face: - forwarder should not be a common case. **Step three**: strategy requests unicast face creation ``` void SelfLearningStrategy::afterReceiveData(const shared_ptr<pit::Entry>& pitEntry, const FaceEndpoint& ingress, const Data& data) { // 1. check if able to find 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 four**: *Forwarder* forwards face creation request sent to *FaceSystem* ``` void Forwarder::createUnicastFaceOnData(const PitEntry& pitEntry, const Data& data) { faceSystem.createUnicastFaceOnData(data, [] (const Face& face) { // STEP FIVE // 1. if PIT entry has been deleted, return // 2. find effective strategy for pitEntry.getName() // 3. strategy.afterUnicastFaceCreation(pitEntry, face) }); } ``` **Step 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 Face (so the ProtocolFactory, which then creates the face ProtocolFactory.createFace(remoteEndpoint, callback); } ``` **Step six** is in the callback function in the step three. **Step seven**: use the newly created face in the callback function ``` void SelfLearningStrategy::afterUnicastFaceCreation(const PitEntry& pitEntry, const Face& face) { // add route out-record can be deleted), and SL strategy learns routes 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 unicast Face.