Tudo se resume à distribuição de probabilidade de perda e padrão de tráfego.
Tomemos, por exemplo, um link sem fio típico, com uma taxa de perda constante de 10 a 30%. Se você confirmar cada quadro recebido (como 802.11abg), detectará rapidamente quando um quadro foi perdido, para não perder tempo para esperar um tempo limite.
Se você preferir NAK, ficará dependente do padrão de tráfego: - Se você enviar um único pacote de solicitação e esperar uma resposta, e essa solicitação for perdida, você terá que ter um tempo limite expirado se não receber uma resposta. responda. - Se você está apenas enviando um fluxo de pacotes a um destinatário quase mudo, é aceitável receber apenas um NAK quando o destinatário receber o próximo pacote. Mas isso significa que o destinatário precisa reordenar pacotes e que o remetente deve acompanhar um grande estoque de mensagens que ele enviou.
(adivinhe qual solução 802.11n escolhe? ambos. O receptor envia um bitmap de tamanho variável dos quadros que recebeu)
Agora, adote uma rede típica da Internet: você tem quase 0% de perda de pacotes, até que algo ruim aconteça, e você tem uma perda de quase 100% de pacotes por um certo tempo, seguindo alguma lei de distribuição exponencial, de uma interrupção de 200ms a um minuto e uma metade.
A aceitação de cada pacote pareceria inútil em uma rede sem perdas, até que você considere o caso em que o link é interrompido: você não receberá ACK ou NACK por um período possivelmente maior e o destinatário normalmente não enviará nada até o link é restaurado.
Se você usar o ACK, o remetente interromperá o envio e manterá a lista de pendências até que o link seja restaurado. Se você usar o NACK, o destinatário poderá dizer-lhe que não recebeu o pacote que caiu da lista de pendências do remetente há muito tempo e que a conexão é essencialmente irrecuperável.