Project

General

Profile

Feature #3967

"ad hoc" property on multi-access face

Added by Junxiao Shi about 3 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Faces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

Introduce a static property to nfd::Face which indicates whether a packet received on this face is expected to have been received by all other nodes on the same link.

  • point-to-point face: it is the only receiver on a link, so a received packet is received by all nodes.
  • multi-access face connected to wired Ethernet: a received packet is almost always received by all nodes on the same broadcast domain.
  • multi-access face connected to ad hoc WiFi: a received packet is only received by nodes within a certain range from the transmitter, but not all nodes in the same ad hoc network

This property is queried by forwarding to determine whether an Interest received on a face can be forwarded out of the same face.

This issue involves:

  • Add LINK_TYPE_AD_HOC value into LinkType.
  • Add face_system.ether.mcast_ad_hoc and face_system.udp.mcast_ad_hoc config options. If the option is set to "yes", created multicast faces should report their LinkType as LINK_TYPE_AD_HOC instead of LINK_TYPE_MULTI_ACCESS.

Related issues

Has duplicate NFD - Task #4018: Extend configuration file to support enabling "ad hoc" face supportClosed03/27/2017

Actions
Blocks NFD - Feature #3968: Forward Interest to ad hoc incoming faceClosed

Actions
Blocks ndn-cxx - Feature #4019: "ad hoc" detection on macOSNew03/27/2017

Actions
Blocks ndn-cxx - Feature #4020: "ad hoc" detection on LinuxIn Progress

Actions
Blocks NFD - Task #4282: Rename LinkType constantsNew

Actions

History

#1

Updated by Junxiao Shi about 3 years ago

  • Blocks Feature #3968: Forward Interest to ad hoc incoming face added
#2

Updated by Teng Liang about 3 years ago

  • Assignee set to Teng Liang
#3

Updated by Teng Liang about 3 years ago

Junxiao Shi wrote:

  • multi-access face connected to wired Ethernet: a received packet is almost always received by all nodes on the same broadcast domain.

Why is it almost? What's the corner case?

A better categorization, I think, is either wired or wireless face. A wireless face should always be allowed to forward both Interest and Data to the incoming face, but a wired face should not. Then we can have a bool property like isWired or isWireless.

#4

Updated by Junxiao Shi about 3 years ago

multi-access face connected to wired Ethernet: a received packet is almost always received by all nodes on the same broadcast domain.

Wired Ethernet has no delivery guarantee. Packet loss is possible, hence "almost".

A wireless face should always be allowed to forward both Interest and Data to the incoming face

Wrong. A WiFi interface operating in STA mode only communicates with the AP. If the AP is NDN-capable, all packets received on this face is sent by the AP, and thus there's no reason to send them back.

but a wired face should not.

Correct.

#5

Updated by Teng Liang about 3 years ago

multi-access face connected to wired Ethernet: a received packet is almost always received by all nodes on the same broadcast domain.

Wired Ethernet has no delivery guarantee. Packet loss is possible, hence "almost".

There is no need to send packet back to the incoming face in this case.

A wireless face should always be allowed to forward both Interest and Data to the incoming face

Wrong. A WiFi interface operating in STA mode only communicates with the AP. If the AP is NDN-capable, all packets received on this face is sent by the AP, and thus there's no reason to send them back.

It is also multi-access face as you classified. If not all multi-access face should forward packet back to the incoming face, why 'multi-access face' is better than 'wireless face'?

#6

Updated by Junxiao Shi about 3 years ago

It is also multi-access face as you classified. If not all multi-access face should forward packet back to the incoming face, why 'multi-access face' is better than 'wireless face'?

Each face is responsibility for reporting whether it's desirable for the strategy to transmit a packet received on the same face.
In the initial implementation, we make the same choice for all multi-access faces, because there is no OS-independent way to reliably identify whether a face is wireless.

#7

Updated by Teng Liang about 3 years ago

Each face is responsibility for reporting whether it's desirable for the strategy to transmit a packet received on the same face.
In the initial implementation, we make the same choice for all multi-access faces, because there is no OS-independent way to reliably identify whether a face is wireless.

Currently, how do we identify whether a face is multi-access or not? As wireless belongs to multi-access, is it more different to identify a wireless face?

#8

Updated by Junxiao Shi about 3 years ago

Currently, how do we identify whether a face is multi-access or not?

The Transport reports whether it's multi-access or not. It's easy to know when the face is created, because the procedures of creating a point-to-point face (ProtocolFactory::createFace) and creating a multi-access face (EthernetFactory::createMulticastFace and UdpFactory::createMulticastFace) are totally separate.
Then, forwarding can inspect LinkType property to know whether a face is multi-access.

As wireless belongs to multi-access, is it more different to identify a wireless face?

Yes, because you can't easily answer "is eth1 a wireless interface?". At least this is not currently in NetworkMonitor API (#3353).

#9

Updated by Teng Liang about 3 years ago

How about having a similar faceType, like ndn::nfd::FACE_TYPE_POINT_TO_POINT and ndn::nfd::FACE_TYPE_MULTI_ACCESS.

#10

Updated by Junxiao Shi about 3 years ago

I agree with note-9 design.
One concern someone may have is that, LinkType property is reported by the Transport but "ad hoc" property may belong to a higher layer. But I argue that whether the face is ad hoc should be known by the Transport, because the definition is "whether a packet received on this face is expected to have been received by all other nodes on the same link" which is a property of the underlying protocol, and not affected by LinkService.

For the constant name, how about LINK_TYPE_AD_HOC?

#11

Updated by Davide Pesavento about 3 years ago

Junxiao Shi wrote:

For the constant name, how about LINK_TYPE_AD_HOC?

As a third (not counting _NONE) value for ndn::nfd::LinkType enum? Sounds good to me.

#12

Updated by Teng Liang about 3 years ago

Seems for this task, we just need to add a constant value LINK_TYPE_AD_HOC for link type. The forwarding task can be done in another thread Ad hoc Forwarding. There is no existing transport that uses this type. How do we test it?

#13

Updated by Junxiao Shi about 3 years ago

Reply to note-12:

There is more than that.
NFD needs a boolean configuration option, when enabled, causes all current LINK_TYPE_MULT_ACCESS faces to report as LINK_TYPE_AD_HOC.
The test is simply enabling this option, and expecting nfdc face list command to show some face's link-type attribute becomes LINK_TYPE_AD_HOC.

To avoid breaking existing logic, before the above configuration option is introduced, another commit should change all "only for point-to-point faces" conditions from != LINK_TYPE_MULTI_ACCESS to == LINK_TYPE_POINT_TO_POINT, and change all "only for multi-access faces" conditions from == LINK_TYPE_MULTI_ACCESS to != LINK_TYPE_POINT_TO_POINT. This ensures any faces now reporting as ad hoc would follow the old logic of multi-access rather than point-to-point.

#14

Updated by Teng Liang about 3 years ago

  • Status changed from New to In Progress
#15

Updated by Teng Liang about 3 years ago

I am trying to detect the mode of a WiFi interface automatically and set the proper link type accordingly. This snippet of code is used for macOS specifically.

#import <Foundation/Foundation.h>
#import <CoreWLAN/CoreWLAN.h>
#import <CoreWLAN/CWInterface.h>
#import <CoreWLAN/CWWiFiClient.h>

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        NSString* interfaceName = @"en0";
        CWWiFiClient* wifiInterface = [[CWWiFiClient alloc] init];
        CWInterface* airport = [wifiInterface interfaceWithName:interfaceName];
        NSLog(@"The mode is : %ld",(long)[airport interfaceMode]);
        if([airport interfaceMode] == 2){
            //ad hoc detected
            NSLog(@"ad hoc");
        }
    }
    return 0;
}
#16

Updated by Teng Liang about 3 years ago

  • % Done changed from 0 to 90
#17

Updated by Teng Liang about 3 years ago

  • % Done changed from 90 to 100
#18

Updated by Teng Liang about 3 years ago

  • % Done changed from 100 to 60
#19

Updated by Junxiao Shi about 3 years ago

I am trying to detect the mode of a WiFi interface automatically and set the proper link type accordingly.

This is of course better than using a configuration. It would be acceptable if you can come up with implementations for every support platform, and it must apply to both Ethernet and UDP multicast faces.

#20

Updated by Davide Pesavento about 3 years ago

Junxiao Shi wrote:

It would be acceptable if you can come up with implementations for every support platform

On Linux, nl80211 can be used for this purpose.

#21

Updated by Junxiao Shi about 3 years ago

I strongly recommend that the "ad hoc" property should be initially implemented as following a configuration option. Attempting platform-specific implementations would take much longer time (remember what happened in #3353) and block related issues (such as forwarding changes).

#22

Updated by Alex Afanasyev about 3 years ago

  • Related to Task #4018: Extend configuration file to support enabling "ad hoc" face support added
#23

Updated by Junxiao Shi about 3 years ago

  • Related to deleted (Task #4018: Extend configuration file to support enabling "ad hoc" face support)
#24

Updated by Junxiao Shi about 3 years ago

  • Has duplicate Task #4018: Extend configuration file to support enabling "ad hoc" face support added
#25

Updated by Alex Afanasyev about 3 years ago

  • Has duplicate deleted (Task #4018: Extend configuration file to support enabling "ad hoc" face support)
#26

Updated by Alex Afanasyev about 3 years ago

  • Related to Task #4018: Extend configuration file to support enabling "ad hoc" face support added
#27

Updated by Alex Afanasyev about 3 years ago

@Junxiao: "Duplicate" has different semantics in current configuration of redmine, as only one task is being tracked (the source of "duplicated by"). The duplicate task is considered closed.

#28

Updated by Alex Afanasyev about 3 years ago

  • Related to deleted (Task #4018: Extend configuration file to support enabling "ad hoc" face support)
#29

Updated by Alex Afanasyev about 3 years ago

  • Related to Task #4018: Extend configuration file to support enabling "ad hoc" face support added
#30

Updated by Alex Afanasyev about 3 years ago

macOS version pushed for review (as part of ndn-cxx API): https://gerrit.named-data.net/#/c/3798/

#31

Updated by Junxiao Shi about 3 years ago

  • Description updated (diff)
  • Estimated time set to 3.00 h

#4018 is indeed a duplicate of this issue. This issue already specifies whether a face is ad hoc should be controlled by a config option. I've updated the description to make this more explicit.

#32

Updated by Junxiao Shi about 3 years ago

  • Related to deleted (Task #4018: Extend configuration file to support enabling "ad hoc" face support)
#33

Updated by Junxiao Shi about 3 years ago

  • Has duplicate Task #4018: Extend configuration file to support enabling "ad hoc" face support added
#34

Updated by Junxiao Shi about 3 years ago

#35

Updated by Junxiao Shi about 3 years ago

#36

Updated by Teng Liang about 3 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 60 to 100

The design and development of adding "ad hoc" property is done. Configuration and automatic detection belong to separate issues now, so this issue is closed.

#37

Updated by Junxiao Shi over 2 years ago

  • Status changed from Closed to Feedback

FaceMgmt page needs to be updated as well.

#38

Updated by Junxiao Shi over 2 years ago

  • Blocks Task #4282: Rename LinkType constants added
#39

Updated by Davide Pesavento about 2 years ago

  • Status changed from Feedback to Closed

Junxiao Shi wrote:

FaceMgmt page needs to be updated as well.

Done.

Also available in: Atom PDF