A municipal GPU cluster needs near-lossless behavior for RoCE storage traffic across the IP fabric. Which CoS approach belongs in the fabric design?
Select an answer to reveal the explanation.
Short Explanation
RoCE storage is like a glass elevator—one hard bump and the ride goes badly. Give those queues the lossless-ish toolkit (PFC/ECN-style patterns on the right paths) instead of treating GPUs like best-effort web downloads.
Full Explanation
A municipal GPU cluster carrying RoCE storage across the IP fabric needs Class of Service that matches RDMA’s sensitivity to loss and congestion. The correct design applies RDMA-oriented CoS—accurate classification plus mechanisms such as Priority Flow Control and Explicit Congestion Notification patterns—on the RoCE-capable leaf-spine paths where buffers and peers are engineered for near-lossless behavior. That scoped toolkit is how civic HPC/storage fabrics keep GPU east-west traffic healthy without treating it as ordinary best-effort web traffic.
Marking all civic traffic as scavenger so RoCE competes equally with backups abandons differentiation and invites storage latency spikes under load. Disabling QoS entirely because “IP fabrics cannot influence RDMA loss” is conceptually false: fabric queues, PFC, and ECN are primary tools for RoCE on Juniper DC fabrics. Using only strict priority for HTTP management sessions while ignoring RDMA markings prioritizes the wrong application class for the stem’s GPU storage problem.
Exam caveat: JN0-683 RoCE items expect PFC/ECN-style treatment on RDMA paths; answers that turn QoS off or prioritize only management HTTP miss the RDMA design goal.
Operational check: map RoCE codepoints to lossless/ECN-aware queues on leaf access, leaf uplinks, and spine fabric ports along the GPU path; generate storage load and confirm pause/ECN activity stays on those classes while scavenger/backup traffic does not share the lossless domain.