injected against inferred, per segment
A path either delivers a packet or drops it, and survival along a path is the product of survival on each segment it crosses. Take logarithms and the whole fleet becomes one linear system: per-path loss measured, per-segment loss unknown. There are always fewer paths than segments, so the system is underdetermined, and a sparsity prior resolves it on the premise that failures are few, not spread evenly.
Everything below runs on measurements a kernel already keeps for every live connection. Place a fault, and the inference sees nothing but the per-path numbers it would cause — then its answer is scored against the fault you placed.
Every flow reports what the TCP stack already counts: packets sent, packets the stack believed lost, packets that arrived out of order, smallest round trip seen, mean round trip, delivery rate. No probe traffic is added and no router is queried.
If segment j drops a fraction xj of what crosses it, a path f delivers the product of (1 − xj) over the segments it crosses. Taking logarithms turns that product into a sum, so the fleet becomes a single linear system:
A x = b with b_f = −ln(1 − loss_f)A is the path-segment incidence matrix, x the unknown
per-segment loss, and b the per-path loss the fleet already measures.
With fewer paths than segments, infinitely many solutions fit. Least squares with an L1 penalty and a non-negativity constraint — projected gradient descent, anything below zero clipped away — selects the sparsest explanation. Loss below zero has no physical meaning, and clipping is what keeps the answer physical.
Two segments crossed by exactly the same set of flows produce identical evidence from every available vantage point. They are grouped and reported as a group; no amount of the same measurements separates them.
Where the loss is and why it happens call for opposite responses, so the mechanism is classified too.
| signature | mechanism | what to do |
|---|---|---|
| latency above its own floor, loss rising with load | a filling queue | back off, move traffic, or add capacity |
| latency flat, loss tracking how far a sender exceeds a rate | a token bucket | pace below the admitted rate; backing off makes it worse |
| latency flat, a fixed drop share at any rate | a lossy medium | do not back off; improve loss recovery |
| loss counted while delivery rate holds | reordering | nothing was dropped; the retransmits are spurious |
A rate limiter drops a share that depends on each sender's rate, which violates the assumption that a segment drops a uniform share of everything crossing it. The linear fit then fails to reproduce the measurements, and that failure is itself the signature: rather than name a segment on a bad fit, the tool checks whether loss correlates with rate and reports a rate limiter when it does.