Forwarder interoperability with Ixia traffic generator

[SLKyrim]

As shown above, my env is similar to Issue#66, where NDNDPDK is activated as a forwarder and connected to an Ixia traffic generator. The NIC is also MT27800 Family [ConnectX-5] 1017, and Linux is 22.04. The NDN-DPDK version is set to 0c34e8b5abb312b6d82bf59395516767bc6f1c72 to be compatible with DPDK 22.07 installed on the server.

NDN interests are generated by Ixia and sent to port 0 (70NI3INGUPHD4), received by the face (7CT2LQTFMLGDLUDF) on port 0. Then, it is forwarded back to Ixia by the face (7CT2LQTFMPMD9UG) on port 1 (70NI3INGUPHD6). However, Ixia does not receive the interests forwarded back by port 1 as expected.

The content of the NDN interests is as shown in the figure below：

And the input cmd and output information are as follows:

$ sudo ndndpdk-ctrl systemd start
$ ndndpdk-ctrl activate-forwarder
Hint: pass parameters via stdin
{}
true
$ ndndpdk-ctrl create-eth-port --pci d9:00.0 --mtu 1500
{"id":"70NI3INGUPHD4","isDown":false,"macAddr":"10:70:fd:11:10:4e","mtu":1500,"name":"0000:d9:00.0","numaSocket":0}
$ ndndpdk-ctrl create-eth-port --pci d9:00.1 --mtu 1500
{"id":"70NI3INGUPHD6","isDown":false,"macAddr":"10:70:fd:11:10:4f","mtu":1500,"name":"0000:d9:00.1","numaSocket":0}
$ ndndpdk-ctrl create-ether-face --local 10:70:fd:11:10:4e --remote 4c:d9:8f:2c:e3:12
{"id":"7CT2LQTFMLGDLUDF"}
$ ndndpdk-ctrl create-ether-face --local 10:70:fd:11:10:4f --remote 4c:d9:8f:2c:e3:14
{"id":"7CT2LQTFMPMD9UG"}
$ ndndpdk-ctrl insert-fib --name /ndn/video/live/202310072149 --nh 7CT2LQTFMPMD9UG
{"id":"7CP2NIVRUGL9NTSGK4EI1N3CNSNIQJB29FNEV9FP4F1BCOR0GGA4G7U290K52G9LJK"}
$ ndndpdk-ctrl get-face --cnt --id 7CT2LQTFMLGDLUDF
{"counters":{"rxData":0,"rxFrames":10,"rxInterests":10,"rxNacks":0,"txData":0,"txFrames":0,"txInterests":0,"txNacks":0},"id":"7CT2LQTFMLGDLUDF","locator":{"local":"10:70:fd:11:10:4e","remote":"4c:d9:8f:2c:e3:12","scheme":"ether"}}
$ ndndpdk-ctrl get-face --cnt --id 7CT2LQTFMPMD9UG
{"counters":{"rxData":0,"rxFrames":0,"rxInterests":0,"rxNacks":0,"txData":0,"txFrames":10,"txInterests":10,"txNacks":0},"id":"7CT2LQTFMPMD9UG","locator":{"local":"10:70:fd:11:10:4f","remote":"4c:d9:8f:2c:e3:14","scheme":"ether"}}

In addition, as shown in the figure below, I also tried to forward interests from a single port. The result showed that port 0 forwarded out NACKs, which seems to be because the name did not match.

$ sudo ndndpdk-ctrl systemd restart
$ ndndpdk-ctrl activate-forwarder
Hint: pass parameters via stdin
{}
true
$ ndndpdk-ctrl create-eth-port --pci d9:00.0 --mtu 1500
{"id":"HH1LIU939OEGM","isDown":false,"macAddr":"10:70:fd:11:10:4e","mtu":1500,"name":"0000:d9:00.0","numaSocket":0}
$ ndndpdk-ctrl create-ether-face --local 10:70:fd:11:10:4e --remote 4c:d9:8f:2c:e3:12
{"id":"HTB54M3S14FGSV1H"}
$ ndndpdk-ctrl insert-fib --name /ndn/video/live/202310072149 --nh HTB54M3S14FGSV1H
{"id":"HTF56U189HAK4TG1A9C439T7JQ0O0NOT3TDFFAC7GGF19TNUGCQGLBRL4UD56QLN3O"}
$ ndndpdk-ctrl get-face --cnt --id HTB54M3S14FGSV1H
{"counters":{"rxData":0,"rxFrames":11,"rxInterests":11,"rxNacks":0,"txData":0,"txFrames":11,"txInterests":0,"txNacks":11},"id":"HTB54M3S14FGSV1H","locator":{"local":"10:70:fd:11:10:4e","remote":"4c:d9:8f:2c:e3:12","scheme":"ether"}}

I wonder if I have made mistakes in my NDN-DPDK settings.

[yoursunny]

The NDN-DPDK version is set to 0c34e8b5abb312b6d82bf59395516767bc6f1c72 to be compatible with DPDK 22.07 installed on the server.

Please upgrade to latest version.
I cannot support any other version.

The content of the NDN interests is as shown in the figure below：
10 70 FD 11 10 4E 4C D0 8F 2C E3 12 86 24 05 2A 07 20 08 03 6E 64 6E 08 05 76 69 64 65 6F 08 04 6C 69 76 65 08 0C 32 30 32 33 31 30 30 37 32 31 34 39 12 00 0A 04 9B ED 18 21 00 00 00 00

Please upload as .pcap or .pcapng next time so that it's easier to analyze.
Nevertheless, the packet seems to be encoded correctly.

$ ndndpdk-ctrl get-face --cnt --id 7CT2LQTFMPMD9UG
{"counters":{"rxData":0,"rxFrames":0,"rxInterests":0,"rxNacks":0,"txData":0,"txFrames":10,"txInterests":10,"txNacks":0},"id":"7CT2LQTFMPMD9UG","locator":{"local":"10:70:fd:11:10:4f","remote":"4c:d9:8f:2c:e3:14","scheme":"ether"}}

This indicates that the packet was transmitted, so there's no problem?

I also tried to forward interests from a single port. The result showed that port 0 forwarded out NACKs

This behavior is by design.
It does not make sense to forward an Interest from face A toward face A, because the peer connected to face A would not have forwarded us the Interest if it had the Data.

[SLKyrim]

Thanks for your kind reply.

If the forwarder settings are not a problem, then I guess NDN-DPDK may have modified the interest packet format, making it unrecognizable by Ixia. Because Ixia cannot capture the packets of txInterests, I wonder if there is a way to capture txInterests packets in Linux or through NDN-DPDK itself.

[SLKyrim]

Close this issue by mistake, now reopen it.

[yoursunny]

NDN-DPDK may have modified the interest packet format

NDN-DPDK does not modify the Interest format.
The Interest format is defined in the NDN Packet Format specification.

The forwarder can modify the Interest packet, such as:

• decrease InterestLifetime by the duration spent in forwarder
• insert HopLimit if not present
• change Nonce for probing
• remove ForwardingHint

I wonder if there is a way to capture txInterests packets in Linux or through NDN-DPDK itself.

Yes, you can try one of these methods:

• Connect the egress port to another Linux computer. Capture traffic with dumpcap or ndntdump.
• Connect the egress port to an Ethernet switch. Configure a mirror port for its traffic. Connect the mirror port to another Linux computer. Capture traffic with the aforementioned tools.
• Use the NDN-DPDK packet dumper feature. When activating NDN-DPDK forwarder, assign an lcore to PDUMP role. During runtime, invoke GraphQL createPdumpWriter and createPdumpFaceSource to dump the traffic to a pcapng file with LinkType=DLT_LINUX_SLL.

[SLKyrim]

Use the NDN-DPDK packet dumper feature. When activating NDN-DPDK forwarder, assign an lcore to PDUMP role. During runtime, invoke GraphQL createPdumpWriter and createPdumpFaceSource to dump the traffic to a pcapng file with LinkType=DLT_LINUX_SLL.

I assigned a pdump role, but no pcap files were generated.

$ jq -n '{
>   eal: {
>     coresPerNuma: { "0": 8 },
>     lcoresPerNuma: { "0": 16 }
>   },
>   lcoreAlloc: {
>     RX: { "0": 4 },
>     TX: { "0": 4 },
>     FWD: { "0": 6 },
>     PDUMP: { "0": 1 }
>   },
>   mempool: {
>     DIRECT: { capacity: 1048575, dataroom: 9146 },
>     INDIRECT: { capacity: 1048575 },
>   }
> }' | ndndpdk-ctrl activate-forwarder
true
$ ndndpdk-ctrl create-eth-port --pci d9:00.0 --mtu 1500
{"id":"R34DS7L7ROVLS","isDown":false,"macAddr":"10:70:fd:11:10:4e","mtu":1500,"name":"0000:d9:00.0","numaSocket":0}
$ ndndpdk-ctrl create-eth-port --pci d9:00.1 --mtu 1500
{"id":"R34DS7L7ROVLU","isDown":false,"macAddr":"10:70:fd:11:10:4f","mtu":1500,"name":"0000:d9:00.1","numaSocket":0}
$ ndndpdk-ctrl create-ether-face --local 10:70:fd:11:10:4e --remote 4c:d9:8f:2c:e3:12
{"id":"RFETAFVOJ8PLHCSK"}
$ ndndpdk-ctrl create-ether-face --local 10:70:fd:11:10:4f --remote 4c:d9:8f:2c:e3:14
{"id":"RFETAFVOJ4Q5DFCL"}
$ ndndpdk-ctrl insert-fib --name /ndn/video/live/202310072149 --nh RFETAFVOJ4Q5DFCL
{"id":"RFAT87TCRHRHFCDDBKQJ4N4Q0SON2O87QCDAQHBUFK6MV1EJLUS46B3MDNPRRFALF8"}
$ ndndpdk-ctrl pdump-face --face RFETAFVOJ8PLHCSK --filename ndndpdk.pcap
{"filename":"ndndpdk.pcap","id":"PNCC6DTIVTRGFVU05HGME","worker":{"id":"PB9S8CD7R8VLG","nid":6,"numaSocket":0}}
{"dir":"RX","face":{"id":"RFETAFVOJ8PLHCSK","locator":{"local":"10:70:fd:11:10:4e","remote":"4c:d9:8f:2c:e3:12","scheme":"ether"}},"id":"PNCC6DTITPI0RRNM64N28KFN71QISCQQHKVVMS8"}
{"dir":"TX","face":{"id":"RFETAFVOJ8PLHCSK","locator":{"local":"10:70:fd:11:10:4e","remote":"4c:d9:8f:2c:e3:12","scheme":"ether"}},"id":"PNCC6DTITPI0RRNM64N28KFN71QISCQQHKVVQS8"}
traffic dumper running, press CTRL+C to stop
^Ctrue
true
$ ndndpdk-ctrl get-face --cnt --id RFETAFVOJ8PLHCSK
{"counters":{"rxData":0,"rxFrames":11,"rxInterests":11,"rxNacks":0,"txData":0,"txFrames":0,"txInterests":0,"txNacks":0},"id":"RFETAFVOJ8PLHCSK","locator":{"local":"10:70:fd:11:10:4e","remote":"4c:d9:8f:2c:e3:12","scheme":"ether"}}

I haven't found any more instructions on how to use the pdump role, so I'm not sure if I've set it up correctly.

[yoursunny]

I assigned a pdump role, but no pcap files were generated.

$ ndndpdk-ctrl pdump-face --face RFETAFVOJ8PLHCSK --filename ndndpdk.pcap
{"filename":"ndndpdk.pcap","id":"PNCC6DTIVTRGFVU05HGME","worker":{"id":"PB9S8CD7R8VLG","nid":6,"numaSocket":0}}

The file is indeed generated.
You used a relative path, so that the file is located in the working directory of the NDN-DPDK service process.
Specifying an absolute path would make it easier to find the file.

ndndpdk-ctrl is merely an API client.
It does not try to transform a relative path to a path relative to its own working directory, because the NDN-DPDK service process could be running inside a container or on a different machine.

I haven't found any more instructions on how to use the pdump role, so I'm not sure if I've set it up correctly.

The instructions are provided as part of GraphQL API.
You can run introspection from a GraphQL client to find them.

[SLKyrim]

It seems that Ixia adds its own identification information after the packet, while NDN-DPDK removes this information, causing Ixia to be unable to recognize the returned packets.

Before being processed by NDN-DPDK, the packets sent by Ixia are as shown below:
10 70 fd 11 10 4e 4c d9 8f 2c e3 12 86 24 05 2a 07 20 08 03 6e 64 6e 08 05 76 69 64 65 6f 08 04 6c 69 76 65 08 0c 32 30 32 33 31 30 30 37 32 31 34 39 12 00 0a 04 9b ed 18 21 a1 8a 2b ad 09 bf df c6 49 78 69 60 60 00 00 00 10 11 12 13 33 8b cf 8f 00 00 29 7c

After being forwarded by NDN-DPDK, the packets received by Ixia are as shown below:
4c d9 8f 2c e3 14 10 70 fd 11 10 4f 86 24 64 40 62 07 f2 ff ff ff ff ff 02 50 35 05 33 07 20 08 03 6e 64 6e 08 05 76 69 64 65 6f 08 04 6c 69 76 65 08 0c 32 30 32 33 31 30 30 37 32 31 34 39 12 00 0a 04 9b ed 18 21 0c 04 00 00 0f 98 22 01 fe 61 37 f9 25

It seems that I need to modify some code to prevent NDN-DPDK from removing Ixia's information.

[yoursunny]

For the incoming packet:

• 10 70 fd 11 10 4e 4c d9 8f 2c e3 12 86 24 is the Ethernet header.
• 05 2a 07 20 08 03 6e 64 6e 08 05 76 69 64 65 6f 08 04 6c 69 76 65 08 0c 32 30 32 33 31 30 30 37 32 31 34 39 12 00 0a 04 9b ed 18 21 is the NDN packet. It has TLV-TYPE 0x05, TLV-LENGTH 0xa1, followed by 0xa1 octets of TLV-VALUE.
• a1 8a 2b ad 09 bf df c6 49 78 69 60 60 00 00 00 10 11 12 13 33 8b cf 8f 00 00 29 7c is what I call "junk". In the codebase it's discarded as Ethernet trailer.

For the outgoing packet, the difference is much more than the removal of "junk".
As you can see:

• The top level TLV is now an LpPacket that carries a PIT token.
• InterestLifetime, and HopLimit are added.

You need to make your traffic generator recognize the NDN packet format, not just matching on byte patterns.
The forwarder is permitted to modify most guider fields and delete any unrecognized fields.
If you want any information in an Interest to pass through the forwarder, you need to put such information as part of the Interest Name or ApplicationParameters.
Please see NDN Packet Format for how to properly encode an Interest.

[SLKyrim]

As for now, By directly commenting and adding some codes, I have implemented the forwarding of interest packets and forwarding data packets manufactured by Ixia along the reverse path. The main modifications are as follows:

For Interest packets:

• In LpHeader_Parse() of lp.c，the length of Ixia info is calculated and added to pkt->pkt_len.
• Because Ixia only counts packets with even lengths，it is necessary to add an if statement in ModifyGuiders_Chained() of interest.c to check whether to skip the padding 0x00 byte in Ixia info, ensuring that the length of the forwarded packet is even. This way, NDN-DPDK can forward Interest packets constructed by Ixia.

For Data Packets:

• The same as Interest, it needs to ensure that Ixia info is preserved during parsing and assembly, and the length of the forwarded Data is even.
• Comment out PitEntry_Timeout_() in pit-entry.c to disable the PIT entry timeout deletion.
• Comment out the entrance of CS_Insert() in fwd-data.c and Pit_RawErase01_() in pit.c to disable the CS to prevent Data from deleting the PIT entry.
• Comment out the if statement for timeout check in FwFwd_DataSatisfy() of fwd-data.c to ensure stable forwarding of Data.

Currently, only one name is being tested. To ensure that Data and Interest carrying this name more conveniently enter the same forwarding thread, the dispatch algorithm in rxloop.c has been changed to InputDemux_DispatchGenericHashDiv().

Surprisingly, after reducing the computational complexity of CS and other functionalities, the Data forwarding rate of one forwarding thread in NDN-DPDK (around 8000 pps) is significantly lower than the forwarding rate mentioned in the paper (around 2 Mpps). I would like to know if there are methods to enhance the forwarding performance of NDN-DPDK in this Ixia env to achieve the performance stated in the paper.

[yoursunny]

After these modifications, the forwarder is no longer conforming to the NDN protocols.
As a result, any benchmark reports are nullified.
Please modify the traffic generator to follow NDN semantics or use the NDN-DPDK traffic generator.