the bandwidth-delay product
Think of a network path as a pipe carrying water. The pipe's width is its bandwidth — how much can flow per second. Its length, in time, is the delay — how long water takes to travel from one end to the other. The amount of water the pipe holds when it is completely full is the product of the two: width times length. The bandwidth-delay product is exactly this — how many bits can be "in flight" inside a path at once, on their way but not yet delivered.
The arithmetic is simply bandwidth times round-trip time. Take a 100 Mbps link with a 40 ms round-trip time: 100,000,000 bits per second times 0.040 seconds is 4,000,000 bits, about 500 KB. That is how much data must be travelling through the path, unacknowledged, to keep the pipe full and busy. Send less than that and the pipe is partly empty — the sender keeps stalling, waiting for acknowledgments before it is allowed to send more, so it never reaches the link's full speed. The bandwidth-delay product is the target a sliding window must reach to use the path efficiently.
This is why a sender's window matters so much, and why it is not just about bandwidth. TCP may send only as many unacknowledged bytes as its window allows; if that window is smaller than the bandwidth-delay product, throughput is capped well below the link speed no matter how fat the link. This is the classic "long fat pipe" problem on high-speed, high-latency paths like satellite or intercontinental links, and the reason TCP needed the window-scaling option to allow windows larger than the old 64 KB limit. Crucially, adding bandwidth raises the product, so a faster link with the same delay needs an even bigger window — more capacity does not reduce delay, it just demands more data in flight to fill.
A satellite path offers 50 Mbps but has a 600 ms round trip. Its bandwidth-delay product is 50,000,000 x 0.6 = 30,000,000 bits, about 3.75 MB. If your TCP window is only 1 MB, you can never push more than 1 MB before stalling for an acknowledgment, capping you near 13 Mbps — a quarter of the link's speed — until the window is enlarged.
Bandwidth times round-trip time gives the bits a path holds when full; a window smaller than this caps throughput far below the link speed.
Adding bandwidth raises the product, so a faster link with the same delay needs an even bigger window to fill — more capacity does NOT reduce latency, and you cannot beat the speed of light for propagation delay.