4 ms·

In TCP if you ACK something that wasn't sent the ACK is dropped.

• kelnos 9y ago
  That's not what's being talked about here. The idea is that you ACK packets that you believe have been sent, but have been dropped or delayed, because you've received a later packet.
  • adrianmonk 9y ago
    Good point. Though that puts this somewhere in a middle ground between a best effort stream and a reliable stream. The ability to throw away data you don't care about is not absolute but is instead conditional upon successfully receiving more data. In a true best effort streaming system, the sender wouldn't retransmit. With this scheme, the sender might retransmit, sometimes, depending on whether certain packets get through and allow certain acks to get sent.
• adrianmonk 9y ago
  That seems easy enough to work around. Send two acks, one for what you really received and one for what you are pretending you've received. If the data has been sent but lost, the sender will accept the aggressive ack. If it hasn't been sent yet, it will accept the less aggressive ack. For that matter, if you have some way of knowing the expected transmission rate (even approximately as long as you can resync to reality), you can blindly send a stream of periodic acks with steadily increasing sequence numbers.