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 59.14%. Comparing base (20b4816) to head (4d56297).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #87      +/-   ##
==========================================
+ Coverage   58.88%   59.14%   +0.25%     
==========================================
  Files          19       19              
  Lines        5833     5833              
==========================================
+ Hits         3435     3450      +15     
+ Misses       2398     2383      -15     

☔ 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 ?