Project

General

Profile

Feature #4973

Self-learning: switching from multicast to unicast on WiFi infrastructure

Added by Teng Liang 26 days ago. Updated 24 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
07/29/2019
Due date:
% Done:

0%

Estimated time:
Tags:

Description

The implementation of #4279 allows NFDs to learn FIB entries through Prefix Announcement piggybacked on Data replying to multicast Interests. The current implementation works poorly with WiFi infrastructure, because a consumer connects to a WiFi AP will always learn routes towards a multicast Face, and multicast performs poorly in WiFi. To solve this issue, self-learning should be able to switch from multicast to unicast while learning routes. This post is to discuss a reasonable implementation design for this feature.

To summarize existing designs:

  • Refactoring Face to be identified from FaceId to FaceId+EndpointId

    • An overkill approach to the described issue with a lot of workload and requiring the forwarding plane to handle EndpointId everywhere
  • Build another self-learning module inside Face to handle EndpointId

    • Still a lot of changes since Face needs to maintain separate PIT and FIB, and handle the verification of prefix announcement (or sync with rib io thread)
  • Send Data to unicast face to reply Interest from multicast face + learning routes to unicast face

    • no Face refactoring or putting SL in Face, minimizing workload

The tasks for the third design include:

  1. Creating unicast Face on receiving Interests from multicast Face

    • Currently, only UDP Face has this feature, so self-learning can prefer UDP multicast face for content discovery
  2. Sending Data to 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 erase the in-record after sending Data.
    • One way is to attach EndpointId to Interests (only to discovery Interests). To find the correct unicast Face, strategy can enumerate all faces and compare EndpointId with their remote Uri.
  3. On receiving Data from unicast Face:

    • forwarder should be able to find the PIT entry sent to the multicast Face (so the out-record can be deleted), and SL strategy learns routes towards the unicast Face.

History

#1 Updated by Davide Pesavento 26 days ago

  • Tags set to SelfLearning
  • Subject changed from self-learning strategy: switching from multicast to unicast on WiFi infrastructure to Self-learning: switching from multicast to unicast on WiFi infrastructure
  • Assignee set to Teng Liang

#2 Updated by Teng Liang 24 days ago

As discussed in the NFD call on July 31, 2019, the third design (with some changes) involves the minimum codebase update. More discussions are needed on next Monday's NFD call.

Here is the basic workflow of how self-learning works with face switching:
1. A consumer multicasts "discovery" Interests to all potential faces, if the consumer has no routes.
2. On receiving Data packets, self-learning checks their incoming Face.

  • if the Face is unicast, self-learning add routes towards the Face (with the same behaviors as in #4279)
  • if the Face is multicast, self-learning creates a unicast face towards the Data sender, and adds routes routes towards the unicast Face.

In this design, face creation is at consumers, and the first Interest-Data exchange is symmetric.

The main task is to create unicast face on receiving data from multicast face.

Also available in: Atom PDF