Bandwidth throttling

RFC 6349 measures whatever rate TCP actually gets. A throttle is a reason that rate sits under the nameplate on purpose. HTTP has no standard throttle header. The limit lives in a client, a server, a proxy, or a traffic shaper.

The cap is usually in bits per second per session, or a shared pool across sessions. A fair scheduler splits a pool. A hard cap stops a session at a number even when the link is idle. Both show up to the user as a slow, steady progress bar rather than a fast bar that stalls.

A nightly MFT job used to fill a 200 Mbps branch link and drop voice calls. Operations set a 40 Mbps ceiling on that job. A 8 GB export then takes 8 × 8 / 40 = 1.6 hours, about 96 minutes, instead of about 5 minutes at full rate. The calls survive. A new operator who removes the ceiling to "fix the slow transfer" restores the five-minute copy and the dropped calls. The throttle was the design. A second cap often hides in the provider plan: after a monthly byte quota, the network slows every flow. That is a quota throttle, not a per-job setting, and it hits uploads and downloads the job did not choose.

Throttling is not congestion. Congestion is the path filling and loss rising. A throttle is stable and documented, or it should be. It is not latency. Adding delay does not cap bits per second by itself. When a transfer is late, ask whether a shaper, a client speed limit, or a provider fair-use rule is in the path before you blame the file size. The log you want is the configured cap next to the measured transfer throughput. If they match, the job is doing what it was told.