Resumo

  • O receptor pode segurar o ACK do primeiro segmento em ordem para confirmar dois de uma vez ou combinar a confirmação com uma resposta local.
  • Segundo segmento, expiração do temporizador e evidência de perda encerram a espera; economia nunca autoriza silêncio indefinido.

O dado já foi aceito quando começa o atraso. O receptor avançou o próximo número esperado; apenas ainda não publicou esse avanço ao emissor. Se outro segmento completo chega, um ACK cumulativo cobre ambos. Se não chega, o temporizador libera a resposta.

O RFC 1122 recomendou delayed ACK para reduzir trabalho nos hosts e tráfego de controle, mas exigiu atraso inferior a 0,5 segundo e recomendou pelo menos um ACK a cada dois segmentos completos. O exemplo de terminal remoto mostrava que a pausa também podia reunir ACK, atualização da janela e caractere de eco.

O RFC 5681 tornou inequívoco que a frequência de um ACK a cada dois segmentos completos é SHOULD e repetiu o teto de 500 ms. Contar apenas 2*RMSS pode alongar demais a confirmação quando o emissor usa segmentos menores por causa da MTU do caminho. Nesse caso, um ACK passa a cobrir mais de dois segmentos reais: o stretch ACK. Para evitá-lo, recomenda-se confirmar pelo menos um de cada dois segmentos recebidos, independentemente do tamanho.

Uma lacuna na sequência muda a prioridade. Segundo a recomendação do RFC 5681, dados acima dela deveriam provocar ACK duplicado imediato; dados que preencham a lacuna total ou parcialmente também deveriam provocar um ACK imediato. A confirmação então informa recuperação de perda, não apenas recepção acumulada.

O RFC 2525 registrou stretch ACK como problema de implementação. Como a chegada de ACKs participa do relógio de controle do emissor, reduzir demais os eventos pode atrasar crescimento e concentrar transmissões em rajadas.