5 ms·

Sorry for the newbie question, but can someone explain why the round trip time is so important for transfer speeds? From the formula I'm guessing something like

by tgb 9y ago

Sorry for the newbie question, but can someone explain why the round trip time is so important for transfer speeds? From the formula I'm guessing something like this happens: server sends DATA to client, client receives DATA then sends ACK to server, server receives ACK and then finally goes ahead and sends DATA2 to the client. But TCP numbers their packets and so I would expect them to continue sending new packets while waiting for ACKs of old packets, and my reading of Wikipedia agrees. So what causes the RTT dependence in the transfer rate?

mburns 9y ago
>But TCP numbers their packets and so I would expect them to continue sending new packets while waiting for ACKs of old packets, and my reading of Wikipedia agrees. TCP keeps a sliding congestion window that relies on RTT. https://en.wikipedia.org/wiki/TCP_congestion_control#Fast_retransmit https://en.wikipedia.org/wiki/TCP_congestion_control#Fast_re...
londons_explore 9y ago
There is something called the receive window. That is the size of data that can be sent before getting more ACK's back. If the delay is longer, and the receive window is the same size, then total throughput is lower.
preinheimer 9y ago
I think this is a good question, I did some reading myself! The blog post talks about "receive windows" which comes into play here. The server will send up to the number of bytes specified in the receive window before needing to start seeing some ACKs. So the shorter the round trip time, the less likely the server is to spend time twiddling it's thumbs waiting for an ack, because it's exhausted its receive window. Of course, increasing the size of the receive window would also help. (I read this answer to get here, I could be way off: https://stackoverflow.com/questions/9613197/what-determines-number-of-data-packets-before-an-ack-is-sent-net-sockets-on-se https://stackoverflow.com/questions/9613197/what-determines-... )
- syncsynchalt 9y ago
  That's right. In the case of a download, the receive window can also be visualized as a limit on the number of packets that are allowed to be "in flight" at once. Shrinking the window is the wrong tool for the job here, like hammering in a screw. It's sensitive to round-trip-time in a way that makes it impossible to equate a given window with a desired speed. A better method might be to monitor download speed and delay ACKs when it exceeds the limit, but traditionally Unix doesn't have a standard API to do this.
motoboi 9y ago
Think about the path between sender and receiver as a pipe. You will have data inside de pipe all the time, the amount of it is a product of bandwidth an latency (pipe length), which is measured as RTT (round-trip time). The sender puts data on the pipe and must wait for acknowledgment from the receiver. How much data should it put on the pipe before the first acknowledgement arrives? If the pipe is too length, the sender will have a lot of data on transit, but this amount will grow over time based on some algorithms (congestion control).
colanderman 9y ago
In a network protocol you generally want to find out as quickly as possible when the receiver has run out of buffer space. Else you're just sending packets it will drop on the floor, because it's unable to process them at the rate you're sending them. (And the buffer space should be small, to minimize latency under load.) But also, you want to keep the pipe full (as explained in the article). So, to balance these opposing requirements, the receiver generally has a buffer which is only somewhat larger than the capacity of the pipe (the bandwidth-latency product). In TCP, the receiver reports the size of this buffer as the receive window. This way the sender knows exactly how much it can send before the receiver's buffers are full. And the receiver's buffer must be large enough to hold at least an RTT's worth of packets, since that is how long it takes (at a minimum) after the sender started sending the data for the sender to hear back from the receiver that it has processed some data and made room in its buffer. Any less and the sender has to stop and wait (like in the article).
syncsynchalt 9y ago
Because Sony has (naïvely) limited download speeds by limiting how many packets can be "in flight" at a given time. Say for example that they clamped it down to a single packet in flight. In that case, if the server was 30ms (round trip time) away then you could only get a packet every 30ms, and if the server was 60ms away then it would cut your speed in half. In normal situations this doesn't happen: your max-packets-in-flight limit (aka your receive window) will eventually scale large enough that it doesn't matter how far you are from a server, the speed will eventually reach the bandwidth limit of the slowest part of the route.

by tgb 9y ago

mburns 9y ago

>But TCP numbers their packets and so I would expect them to continue sending new packets while waiting for ACKs of old packets, and my reading of Wikipedia agrees. TCP keeps a sliding congestion window that relies on RTT. https://en.wikipedia.org/wiki/TCP_congestion_control#Fast_retransmit https://en.wikipedia.org/wiki/TCP_congestion_control#Fast_re...

londons_explore 9y ago

There is something called the receive window. That is the size of data that can be sent before getting more ACK's back. If the delay is longer, and the receive window is the same size, then total throughput is lower.

preinheimer 9y ago

I think this is a good question, I did some reading myself! The blog post talks about "receive windows" which comes into play here. The server will send up to the number of bytes specified in the receive window before needing to start seeing some ACKs. So the shorter the round trip time, the less likely the server is to spend time twiddling it's thumbs waiting for an ack, because it's exhausted its receive window. Of course, increasing the size of the receive window would also help. (I read this answer to get here, I could be way off: https://stackoverflow.com/questions/9613197/what-determines-number-of-data-packets-before-an-ack-is-sent-net-sockets-on-se https://stackoverflow.com/questions/9613197/what-determines-... )

syncsynchalt 9y ago
That's right. In the case of a download, the receive window can also be visualized as a limit on the number of packets that are allowed to be "in flight" at once. Shrinking the window is the wrong tool for the job here, like hammering in a screw. It's sensitive to round-trip-time in a way that makes it impossible to equate a given window with a desired speed. A better method might be to monitor download speed and delay ACKs when it exceeds the limit, but traditionally Unix doesn't have a standard API to do this.

motoboi 9y ago

Think about the path between sender and receiver as a pipe. You will have data inside de pipe all the time, the amount of it is a product of bandwidth an latency (pipe length), which is measured as RTT (round-trip time). The sender puts data on the pipe and must wait for acknowledgment from the receiver. How much data should it put on the pipe before the first acknowledgement arrives? If the pipe is too length, the sender will have a lot of data on transit, but this amount will grow over time based on some algorithms (congestion control).

colanderman 9y ago

In a network protocol you generally want to find out as quickly as possible when the receiver has run out of buffer space. Else you're just sending packets it will drop on the floor, because it's unable to process them at the rate you're sending them. (And the buffer space should be small, to minimize latency under load.) But also, you want to keep the pipe full (as explained in the article). So, to balance these opposing requirements, the receiver generally has a buffer which is only somewhat larger than the capacity of the pipe (the bandwidth-latency product). In TCP, the receiver reports the size of this buffer as the receive window. This way the sender knows exactly how much it can send before the receiver's buffers are full. And the receiver's buffer must be large enough to hold at least an RTT's worth of packets, since that is how long it takes (at a minimum) after the sender started sending the data for the sender to hear back from the receiver that it has processed some data and made room in its buffer. Any less and the sender has to stop and wait (like in the article).

syncsynchalt 9y ago

Because Sony has (naïvely) limited download speeds by limiting how many packets can be "in flight" at a given time. Say for example that they clamped it down to a single packet in flight. In that case, if the server was 30ms (round trip time) away then you could only get a packet every 30ms, and if the server was 60ms away then it would cut your speed in half. In normal situations this doesn't happen: your max-packets-in-flight limit (aka your receive window) will eventually scale large enough that it doesn't matter how far you are from a server, the speed will eventually reach the bandwidth limit of the slowest part of the route.