The Network Redistributes the Latency Budget
NVMe-oF carries the command set across RDMA, TCP or FC, adding a hop between host and drive. Inside a data centre that hop typically costs tens of microseconds, which looks like it should dilute per-drive latency differences. The opposite happens: network jitter stacks on top of the drive's tail, and a single read-latency spike from background garbage collection queues up and amplifies at the target. Disaggregation changes the requirement from low average latency to a narrow latency distribution.
RDMA Versus TCP Is Not an Either/Or
RDMA costs little CPU and holds latency steady but is sensitive to lossless network configuration. NVMe/TCP reuses existing Ethernet with a much lower deployment barrier, paying for it in target-side CPU load and protocol stack jitter. Large deployments usually end up mixed: RDMA for latency-sensitive tiers, TCP for capacity tiers. For the drive this rules out assuming any fixed upper-layer queue model — firmware QoS must stay predictable as concurrency varies from light to heavy, not merely optimal at one test point.
The Queueing Happens After the Network
A target serves several initiators at once, and every volume the host sees is, on the drive, just a namespace. How finely isolation can be drawn is settled by the drive: a namespace separates LBA space and fault domain, while physical blocks, back-end channels and the garbage collection engine stay shared. One initiator's large sequential write therefore queues inside the drive and stretches another's small reads, and that queueing sits downstream of the network, where no network-layer rate limit can reach it. Only two levers work — put the QoS enforcement point inside the drive, and require the drive to emit performance data resolvable to a specific namespace. Without both, the target sees nothing but an averaged aggregate throughput.
The Target's Fault Domain Is Bigger Than One Drive
After disaggregation a single target host commonly fronts dozens of drives, so a host, cable or switch failure exposes data at chassis scale. The dual-port models carrying the D suffix — J760D and J780D in TITAN 7, J760QD and J960QD on the QLC lines — exist for exactly this layer: one drive presents PCIe paths to two controllers, and when one side goes unreachable I/O continues on the other. What that buys is a narrower fault domain, not doubled bandwidth. The disaggregated front end itself rests on two Gen5 lines: TITAN 9 in U.2/U.3 for AI servers, databases and cloud platforms, FLEX 9 in E3.S and E1.S for OCP cloud data centres and dense nodes, with the form factor usually decided by chassis and backplane first. Both lines sit in the product-definition/EVT window and the capabilities above are planning scope; a latency distribution is something to replay and measure on the target software stack, never to extrapolate from a drive's standalone numbers.