# Connection And Network Path

## Question

Which exact hop is slow or failing, and is transport behavior the mechanism or
only correlated with the incident?

## Enter When

Use for connection setup delay, timeout, disconnect, TiDB client backoff,
component RPC latency, bandwidth saturation, packet/path interruption, or
load-balancer/backend suspicion.

## First Batch

1. Identify the user-visible connection/RPC/backoff result on the affected
   client, server, instance, and exact samples.
2. Compare the matching client and server sides of one hop:
   TiDB–TiKV, TiDB–PD, PD–PD, or TiKV–TiKV.
3. Check the strongest competing boundary: server processing/queue, service
   unavailability, or bandwidth/host saturation.

## Decision

Distinguish interruption, latency jitter, and bandwidth saturation. Client
latency without server latency can indicate the network or client-local path;
both rising can indicate server-side work, but neither pattern alone proves the
deeper cause. `unreachable` can also result from a busy or stuck gRPC/service
thread. Generic ICMP/TCP success proves only the tested hop.

## Strongest Alternative And Stop

Require bounded per-point, per-instance evidence. If the provider returns only
aggregates or a window maximum without its sample timestamp, keep the
conclusion suspected or inconclusive and call the relationship
`window-aligned`, not simultaneous or ordered. Name the per-point aligned
series needed. For PD/etcd peer RTT, compare same-window WAL/backend/disk or a
direct host/network signal before naming network as the deeper trigger. Stop
after one exact hop and its strongest non-network alternative are bounded.