[Jafaral]

Move bridged TC off the node NIC and add directional and per-peer constraints

Host-to-switch delay/rate/loss used to be installed as the node NIC's root qdisc, replacing whatever the DUT configured. The switch now shapes both directions on its port: netem/tbf on egress for traffic toward the node, and an IFB on ingress for traffic from the node. P2P links keep TC on the node interface.

Constraints can be wrapped in transmit and receive containers, relative to the owner of the config. On a network, transmit is traffic toward the node and receive is traffic from it. On a node connection, transmit is what the node sends and receive is what it receives. Unwrapped constraints still work, are deprecated, and mean transmit. Where network and node values overlap, the node's value wins. For P2P links, a node's receive is applied on the peer's egress.

A network connection's transmit can also list peers, giving traffic from a specific sender toward that node its own constraints. Each port marks incoming packets per sender, and the receiving port classifies on that mark into per-peer drr classes, so this works for VMs and broadcast too.

The YANG, README tree and JSON schema are updated, and there are tests for each case.

Example:

networks:
  - name: radio
    connections:
      - to: r1
        transmit: { delay: 2000 }    # radio -> r1
        receive:  { delay: 2000 }    # r1 -> radio
      - to: r2
        transmit:
          delay: 5000                # anyone -> r2
          peers:
            - peer: r1               # r1 -> r2 only
              delay: 30000
              loss: 5
nodes:
  - name: r1
    connections: [ { to: radio } ]
  - name: r2
    connections:
      - to: radio
        receive: { loss: 1 }         # r2 RX, applied on the switch port

[liambrady]

I like your changes to TC with the usage of IFBs. I think we need to revisit the to/from config syntax before that portion gets merged, though.

[liambrady]

Why does the usage of _tc_constraints() differ in the host-to-host and host-to-switch cases? Is merging required only in host-to-switch case?

[liambrady]

Never mind. I see that the behavior is corrected in the next commit. It is probably worth cleaning this up to ensure the history clean.

[liambrady]

While I like the idea of configuring egress/ingress link metrics from the same network, I don't think that the definition of a new from leaf is the way to go. Specifically, I would like to strictly adhere to standard YANG for new config, however, your usage of to and from as mutually exclusive key values cannot (to my knowledge) be modelled in YANG.

Furthermore, I don't see how the from can be extended to the config of ingress TC metrics for the typical node connections (which would be a suitable follow up feature). The presence of further config (e.g. hostintf, physical, ip, etc.) wouldn't quite make sense in the from context. (e.g. Why would I be configuring node A's interface from the context of node B?).

I think it makes more sense to wrap the TC metrics in new transmit/receive containers, to specify whether the metrics apply to local egress or ingress traffic. That would make both the direction of the rules clear and prevent conflicts with the usage of to as a key. (Note: the usage of the current TC metrics without the transmit/receive container would continue to have to be supported but should be labelled as deprecated under this approach.)

For example, my vision is:

|  |  +--rw connections* [to]
|  |     +--rw to                    string
|  |     +--rw name?                 string
|  |     +--rw remote-name?          string
|  |     +--rw transmit
|  |     | +--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 receive
|  |       +--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

[codecov]

Codecov Report

❌ Patch coverage is 97.97980% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 61.02%. Comparing base (e7ed4d5) to head (19bb492).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
munet/base.py	95.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #101      +/-   ##
==========================================
+ Coverage   60.55%   61.02%   +0.47%     
==========================================
  Files          19       19              
  Lines        5990     6076      +86     
==========================================
+ Hits         3627     3708      +81     
- Misses       2363     2368       +5     

☔ View full report in Codecov by Harness.
📢 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.