munet: expose network intf to tc

[liambrady]

tc network parameters are configured once per-network, with attached interfaces inheriting the configuration. This contrasts node config, wherein the same tc network parameters are exposed on a per-connection (i.e. per-interface) basis.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.16%. Comparing base (e4383c4) to head (bfee4d5).
⚠️ Report is 18 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #87      +/-   ##
==========================================
+ Coverage   59.19%   60.16%   +0.96%     
==========================================
  Files          19       19              
  Lines        5833     5879      +46     
==========================================
+ Hits         3453     3537      +84     
+ Misses       2380     2342      -38     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[liambrady]

NAK: Need a solution that allows each connection of the network to be modified independently. An open suggestion is to configure values on the Node-side instead of Network-side.

[liambrady]

There are two paths forward that I can see regarding enabling the per-connection config of loss, latency, etc. for networks:

1. Support the configuration of network values on a connection-level basis.

The updated networks schema would be as follows:

+--rw topology
     +--rw networks* [name]
        +--rw name                  string
        +--rw ip?                   string 
        +--rw ipv6?                 string 
        +--rw external?             boolean
        +--rw delay?                uint64 
        +--rw jitter?               uint64 
        +--rw jitter-correlation?   decimal64
        +--rw loss?                 uint64    
        +--rw loss-correlation?     decimal64
        +--rw rate
        |  +--rw rate?    number64
        |  +--rw limit?   number64
        |  +--rw burst?   number64
        +--rw connections* [to]
           +--rw to                    string
           +--rw delay?                uint64 
           +--rw jitter?               uint64 
           +--rw jitter-correlation?   decimal64
           +--rw loss?                 uint64    
           +--rw loss-correlation?     decimal64
           +--rw rate
              +--rw rate?    number64
              +--rw limit?   number64
              +--rw burst?   number64

Wherein the network-level config is the default for all interfaces managed by the network, and connection-level config is more specific. Note that the connection-level config was actually swapped out with network-level config within this PR (LoC 3198 in native.py. Note: connection-level config was undocumented albeit functional). Therefore, adding it back in is a simple two-line change to this PR.

2. Maintain schema, but make configured loss, latency, etc. metrics bidirectional

For example, loss would be configured in a topology as follows:

topology:
  networks:
    - name: net1
  nodes:
    - name: r1
      connections:
        - to: net1
          loss: 50  # Implicitly configures 50% loss on opposite end of the veth (in net1)
        - to: r2
          loss: 30
    - name: r2
      connections:
        - to: r1
          loss: 30  # Either must match r1 config or is implicitly configured if absent due to r1 config

This technically reduces the set of offered functionalities (since munet would no longer support connections with unequal tx/rx metrics.) However, this might be more intuitive to a user who is not familiar with how the metrics are being applied under the hood (e.g. via tc).

Thoughts:

Personally, I prefer option 1 since it maintains unequal tx/rx functionality that might have a valid use case in certain realistic topologies. A page in the docs can always be added to explain how it is applied under the hood.

Do you have any insight/opinions @choppsv1 ?

[choppsv1]

I've pushed a new smaller code change. The code checks if the returned switch.connections config is empty and if so adds tc values from the root of switch config as the network side connection config. The add_native_link changes weren't needed as long as you don't include the switch "name" key from the root config in the interface config dict you pass in.

Unfortunately I didn't force push the rebase first so the diff when you click the compare link in github is not very useful :(

[choppsv1]

LGTM