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.
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.
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_acknowledgm... Note that the original article isn't talking about the case where packets are being lost.
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.
It does send multiple packets (which helps throughput), but it doesn't cut down on latency. Round trip time is hard to improve.
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.