 |
Local credit is useful, but attackers can move across domains. So we synchronize trust views.
We use a lightweight gossip protocol that runs every 2 seconds. In each round, a node randomly selects one or two neighbors and sends a summary of the top 50 DIDs whose credit changed beyond a threshold 0.1.
Each summary record includes a tuple like DID, credit, timestamp, signature.
Receivers keep the latest valid signed record and update local credit accordingly.
Because each node exchanges only O records per round with a constant number of neighbors, overhead stays small. In our simulations, the additional gossip traffic stays below about 2% of observed control-plane traffic.
Now, how do we use credit?
For forwarding and rate control, high-credit entities get priority and loose limits, while low-credit entities are throttled or blocked.
For credit-aware caching, content requested by high-credit entities is preferentially cached and retained longer, while content induced by low-credit entities is generally not cached or is evicted first.
So credit directly becomes an operational control knob for both caching and forwarding behavior. |
IEEE/ICACT20260343 Slide.20
[Big Slide]
[YouTube]