Latency

RFC 6298 uses that round-trip sample to set TCP's retransmission timer. It is not a rate. A path can have high latency and high bandwidth at the same time. Satellite links are the textbook case.

For a single long upload, latency matters less once the pipe is full. The bytes are limited by bandwidth and loss. Latency matters when the transfer is chatty. FTP's control commands, a WebDAV PROPFIND per folder, and a thousand tiny file uploads each wait on a round trip. A 200 ms path turns a listing of 1,000 files into minutes if the client does not pipeline. SFTP and HTTPS can pipeline. A client that does not will look "slow" on a link whose bandwidth is fine.

A sync job copies 4,000 RAW files, 20 MB each, from a laptop to a server 180 ms away. One request at a time, with a handshake per file, spends 4,000 × 0.18 = 720 seconds, twelve minutes, before any payload. The payloads at 100 Mbps want about 6,400 seconds. The chatter is not the whole job, but it is a fixed tax a zip of the same files would pay once. RFC 6349's bandwidth-delay product is the other face of this: throughput cannot exceed the window divided by the round trip. A small window on a long path leaves bandwidth idle. Raising the window, or using a protocol that keeps more bytes in flight, is the fix. Buying a "faster" plan does nothing if the window was the limit.

Latency is not queueing delay from congestion, though the two add. A ping measures the empty path. A transfer measures the loaded one. Report both if a job is late. Do not call latency "speed." Speed in this glossary is transfer throughput.