Все сводится к распределению вероятности потерь и типу трафика.
Возьмем, к примеру, типичное беспроводное соединение с устойчивым уровнем потерь 10-30%. Если вы подтвердите каждый полученный кадр (например, 802.11abg), вы быстро обнаружите, когда кадр был потерян, поэтому вы не потеряете время для ожидания тайм-аута.
Если вместо этого вы использовали NAK, вы будете зависеть от схемы трафика: - Если вы отправляете один пакет запроса и ожидаете ответа, и этот запрос теряется, у вас должен быть тайм-аут, который истекает, если вы не получаете ответ. - Если вы просто отправляете поток пакетов практически беззвучному получателю, то приемлемо получать NAK только тогда, когда получатель получит следующий пакет или около того. Но это означает, что получатель должен переупорядочить пакеты и что отправитель должен отслеживать большой список невыполненных отправленных им сообщений.
(угадайте, какое решение выберет 802.11n? и то и другое. Получатель отправляет битовую карту с переменной длиной кадра, которую он получил)
Теперь возьмем типичную сеть Интернет: у вас потеря пакетов близка к 0%, пока не случится что-то плохое, и у вас будет потеря пакетов, близкая к 100%, в течение определенного времени, следуя некоторому экспоненциальному закону распределения, от прерывания 200 мс до минуты и половина.
Захватывать каждый пакет в сети без потерь может показаться бессмысленным, пока вы не рассмотрите случай, когда связь разорвана: вы не будете получать ACK или NACK в течение возможно длительного промежутка времени, а получатель, как правило, не будет отправлять что-либо до соединения восстанавливается.
Если вы используете ACK, отправитель прекратит отправку и сохранит свое отставание до восстановления ссылки. Если вместо этого вы используете NACK, то получатель может в конечном итоге сказать вам, что он не получил пакет, который долгое время оставался в резерве отправителя, и соединение по существу невозможно восстановить.