NFV Tunnel Performance

The NFV tunnel uses TCP transport and can handle both delay and a certain amount of packet loss without losing the PM function.

This is shown in the table below:

*Note: Applicable only for reduced footprint use cases, see, Reduced NFV PM Footprint Configuration for more information.

The limiting factor to consider is the total amount of bandwidth that the tunnel can carry, this can then be used to calculate how many PM sessions, of a certain type, would be safe to use for a specific situation.

If the Module is placed “close” to the sensor: control, i.e in the same rack or datacenter, the delay between the sensor: control and the Module will be negligible and it would be possible to use up to the max capacity of 2,000 simultaneous TWAMP sessions at 20PPS per Module (total of 4,000 per sensor: control if using two Modules).

Note: 100ms is a very long distance (Amsterdam <-> Washington) and typically this type of link is not suitable for NFV-type functions.

Would you place your VNF Firewall in US for a service in Netherlands?

Example:

If the Module is deployed 50 milliseconds away from the sensor: control (100ms roundtrip) then the max PM bandwidth using this Module as an NFV sender will be 12.5Mbps. If occasional packet loss is expected, this drops to 4Mbps. This is because the tunnel will have to start buffering and retransmit the lost packets.

To test capacity

To test for capacity between the sensor: control and the Module during deployment and provisioning, verify that:

1. Test methodology can either be TWAMP generated from the sensor: control (controlled from skylight orchestrator) or a layer-3 SAT test from a Module close to the sensor: control, towards the Module to be tested.

2. To test for 12.5Mbps, set up a test transmitting 1,030 packets per second with packet size 1500B (Ethernet payload size)

| BW (Mbps) | Throughput test packets per second - 1500B ETH payload |
| --- | --- | ---|
| | IPv4 (1472B | IPv6 (1452B |
| 100 | 500 | 500 |
| 12.5 | 1,030 | 1,030|
| 25 | 2,060 | 2,060 |
| 50 | 4,120 | 4,120 |
| 62 | 5,110 | 5,110 |

To validate test results

To validate the test results, check if:

1. The test shows lower throughput than the desired bandwidth (ideally measured over 24hrs on a weekday)

2. Occurrences of packet loss that are over 0.01% are present

3. RTT is varying more than 10% over time (50ms and up)

If none of the above is true, then this path is sufficient to carry the NFV tunnel.

This table can be used to quickly assess how many PM sessions (TWAMP) correspond to a specific NFV tunnel bandwidth. To illustrate this using the same 100ms/12.5Mbps number, it would amount to 625 concurrent TWAMP sessions through the NFV tunnel if, using the default 82Byte IP payload size (=128Byte Ethernet on the wire).

The calculation is linear, so 50ms RTT = 100ms RTT.

| RTT (ms) | BW (Mbps) | Number of 20pps TWAMP sessions in tunnel - 128B ETH payload
| --- | --- | ---| ---|
| | | IPv4 (82B) | IPv6 (62B) |
| 200 | 6 | 300 | 300 |
| 100 | 12.5 | 625 | 625 |
| 50 | 25 | 1,250 | 1,250 |
| 25 | 50 | 2,000 | 2,000 |
| 10 | 62 | 2,000 | 2,000 |