the round-trip time
If you shout across a canyon and time how long until you hear your own echo, you have measured a round trip: the time for your sound to travel out and the reflection to come back. On a network, the round-trip time, or RTT, is the time from when a sender launches a packet to when it gets back the acknowledgment for it — the out-and-back delay for one piece of data and its reply.
RTT is built from several pieces added together: the propagation delay (how long the signals physically take to travel the distance, limited by the speed of light), the transmission time (how long it takes to clock the bits onto the wire), and the queuing and processing delays at every router along the path, both directions. Crucially, RTT is not fixed — when routers get busy and their buffers fill, queuing delay grows and RTT rises. TCP measures RTT continuously by timing its own acknowledgments and keeps a smoothed running estimate (and a measure of how much it varies), because so much of its behaviour is paced by it.
RTT matters because it is the heartbeat of TCP. Throughput is roughly the congestion window divided by RTT, so a long RTT directly caps how fast a connection can go for a given window. RTT also sets how quickly TCP can react: each adjustment to the congestion window happens once per round trip, so a path with a 200 ms RTT to the other side of the world reacts ten times more slowly than a 20 ms local path. And rising RTT is itself a congestion signal — the basis of delay-based controllers like BBR and Vegas, which slow down when they sense the queue (and thus RTT) growing, before any packet is even lost.
A ping from London to a server in Sydney might report an RTT around 280 ms — most of it pure propagation delay, because light through fibre simply cannot cross half the planet faster. A ping to a server in the same city might report 5 ms. Adding bandwidth to either link does NOT shrink that RTT; you cannot beat the speed of light over distance.
RTT is dominated by distance (propagation delay) plus any queuing; more bandwidth does not reduce it.
A common confusion: bandwidth and RTT are independent. A fat pipe can still have a long RTT (a satellite link is high-bandwidth but very high-latency), and adding bandwidth never lowers propagation delay. TCP's reaction speed and its peak throughput per window are both gated by RTT, not by how wide the pipe is.