Like someone else said, these are called NACKS. In theory, this would be a good way to do it but I think there are implementation problems. Also, using regular ACKS doesn't incur as much overhead and is useful in other ways:
1) ACKS are cumulative, not one for every packet. TCP sends packets in groups (windows) and the entire group gets acked at once if received correctly. (note: varying the size of the group/window is how the send rate is adjusted which is what started this whole discussion)
2) ACKS can often be piggy-backed onto data being sent in the opposite direction and in fact every TCP frame has a field especially for this purpose. This greatly reduces the number of dedicated ACK packets that need be sent.
3) The congestion control algorithms that are in use now (and are used by FAST) work by having congested routers set bits in the ACK packets going back to the source. When the sender sees these panic bits, it slows down. This requires a steady stream of packets going back to the sender which you can't depend on with a pure NACK approach.
Whoever wrote these articles is not the brightest crayon in the box. Their explanations of how "regular" TCP works and how FAST works are both exceedingly wrong. Read the FAST group's overview for an explanation of what they're doing. It's semi-heavy with technical networking terms but you'll learn that this has nothing to do with error checking.
Congestion control based on roundtrip times is old news but is uncommon AFAIK. What really happens is direct feedback from routers along a transmission's path. This is done in TCP Vegas, which was first proposed in 1994 and I think is fairly common now. The problem with scaling this or any of the other common TCP implementations to high speed/high delay links is the reaction to detected congestion. "Normal" TCP aggressively scales back its send window (send rate) when it detects congestion, usually chopping it in half. The window/rate then grows linearly until something goes wrong again. This results in alot of lost throughput in high-speed networks especially if the amount of "real" congestion is low. The FAST group is working on a new TCP implementation that doesn't react so aggressively to congestion. This is great for those high-speed/low-congestion networks we all wish really existed but is not something you want to use on the always-backed-up Internet. Would probably make things worse.
Slashdot Mirror
Like someone else said, these are called NACKS. In theory, this would be a good way to do it but I think there are implementation problems. Also, using regular ACKS doesn't incur as much overhead and is useful in other ways:
1) ACKS are cumulative, not one for every packet. TCP sends packets in groups (windows) and the entire group gets acked at once if received correctly. (note: varying the size of the group/window is how the send rate is adjusted which is what started this whole discussion)
2) ACKS can often be piggy-backed onto data being sent in the opposite direction and in fact every TCP frame has a field especially for this purpose. This greatly reduces the number of dedicated ACK packets that need be sent.
3) The congestion control algorithms that are in use now (and are used by FAST) work by having congested routers set bits in the ACK packets going back to the source. When the sender sees these panic bits, it slows down. This requires a steady stream of packets going back to the sender which you can't depend on with a pure NACK approach.
Congestion control based on roundtrip times is old news but is uncommon AFAIK. What really happens is direct feedback from routers along a transmission's path. This is done in TCP Vegas, which was first proposed in 1994 and I think is fairly common now. The problem with scaling this or any of the other common TCP implementations to high speed/high delay links is the reaction to detected congestion. "Normal" TCP aggressively scales back its send window (send rate) when it detects congestion, usually chopping it in half. The window/rate then grows linearly until something goes wrong again. This results in alot of lost throughput in high-speed networks especially if the amount of "real" congestion is low. The FAST group is working on a new TCP implementation that doesn't react so aggressively to congestion. This is great for those high-speed/low-congestion networks we all wish really existed but is not something you want to use on the always-backed-up Internet. Would probably make things worse.