4 ms·

Does anyone know why the system doesn't send over 10 packets at once, then check those packets, then ask for the packets that are not received. Wouldn't doing

Does anyone know why the system doesn't send over 10 packets at once, then check those packets, then ask for the packets that are not received. Wouldn't doing it that way cut down on the latency signifigantly? (or send the entire file, 1000s of packets) determine which don't make it and just ask for those? This isn't my area of expertise, so I'm just curious.

thereallurch 14y ago
http://en.wikipedia.org/wiki/Sliding_window_protocol http://en.wikipedia.org/wiki/Sliding_window_protocol It does send multiple packets (which helps throughput), but it doesn't cut down on latency. Round trip time is hard to improve.
jgrahamc 14y ago
Two things: 1. TCP wasn't designed like that. It uses a rather simple scheme of sending back a byte count telling the other side up to what byte number it has received. So there's no provision for telling the other side that a bit in the middle is missing. 2. We don't send 1000s of packets at once because doing so would cause congestion on the Internet. So there's a whole subsystem in TCP that tries to determine the capacity of the link between two points and avoid creating congestion. 3. But the scheme you describe was actually added to TCP and it's called SACK: http://en.wikipedia.org/wiki/ACK_(TCP)#Selective_acknowledgments http://en.wikipedia.org/wiki/ACK_(TCP)#Selective_acknowledgm... Note that the original article isn't talking about the case where packets are being lost.
- ajross 14y ago
  Note that SACK is enabled by default on all modern TCP implementations, so #1 really isn't an issue. And the 1000's of packets thing isn't quite right either. With windows scaling (another option pervasively enabled) and a fat pipe (it does take some time for the algorithm to ramp up that far), you can have about 1GiB in flight on the wire at any time, that's hundreds of thousands of packets.
johngalt 14y ago
Why can't you send the entire file? Because your LAN connection is probably 1000Mbps and your internet connection is likely <5Mpbs. Or the receiving sides internet connection is 2Mbps. Your computer only sees 1000Mbps and would dump a 1tb file out at line rate. Then it would ask 'what pieces are missing?' And have to send 99% of the file again. Even worse if multiple people are trying to send to the same recipient. So instead we ask the receiving side how big its buffer is and only send that much before awaiting a response (in many cases more than 10 at a time). If there is network congestion that response will take longer automatically slowing the transmission rate. The problem is that TCP can't tell the difference between congestion latency and distance latency.

thereallurch 14y ago

http://en.wikipedia.org/wiki/Sliding_window_protocol http://en.wikipedia.org/wiki/Sliding_window_protocol It does send multiple packets (which helps throughput), but it doesn't cut down on latency. Round trip time is hard to improve.

jgrahamc 14y ago

Two things: 1. TCP wasn't designed like that. It uses a rather simple scheme of sending back a byte count telling the other side up to what byte number it has received. So there's no provision for telling the other side that a bit in the middle is missing. 2. We don't send 1000s of packets at once because doing so would cause congestion on the Internet. So there's a whole subsystem in TCP that tries to determine the capacity of the link between two points and avoid creating congestion. 3. But the scheme you describe was actually added to TCP and it's called SACK: http://en.wikipedia.org/wiki/ACK_(TCP)#Selective_acknowledgments http://en.wikipedia.org/wiki/ACK_(TCP)#Selective_acknowledgm... Note that the original article isn't talking about the case where packets are being lost.

ajross 14y ago
Note that SACK is enabled by default on all modern TCP implementations, so #1 really isn't an issue. And the 1000's of packets thing isn't quite right either. With windows scaling (another option pervasively enabled) and a fat pipe (it does take some time for the algorithm to ramp up that far), you can have about 1GiB in flight on the wire at any time, that's hundreds of thousands of packets.

johngalt 14y ago

Why can't you send the entire file? Because your LAN connection is probably 1000Mbps and your internet connection is likely <5Mpbs. Or the receiving sides internet connection is 2Mbps. Your computer only sees 1000Mbps and would dump a 1tb file out at line rate. Then it would ask 'what pieces are missing?' And have to send 99% of the file again. Even worse if multiple people are trying to send to the same recipient. So instead we ask the receiving side how big its buffer is and only send that much before awaiting a response (in many cases more than 10 at a time). If there is network congestion that response will take longer automatically slowing the transmission rate. The problem is that TCP can't tell the difference between congestion latency and distance latency.