Resumo

  • O RFC 3465 propôs Appropriate Byte Counting: aumentar a janela TCP pelos bytes antes não confirmados cobertos por um ACK, em vez de conceder um incremento fixo a cada mensagem ACK.
  • A prova em bytes continuava limitada. L restringia o aumento por ACK no slow start, não podia exceder dois SMSS e devia cair para um SMSS após RTO, quando uma confirmação cumulativa podia incluir progresso antigo.

O número de comprovantes não media o avanço

O crescimento tradicional de cwnd tratava cada ACK recebido como uma oportunidade. A aproximação era simples quando o receptor confirmava cada segmento e nenhum aviso se perdia. Com ACK atrasado, porém, os mesmos bytes geravam menos mensagens e a janela crescia mais devagar. Com ACK division, um receptor podia confirmar pequenas partes sucessivas de um segmento e fabricar várias oportunidades para a mesma entrega.

Publicado como Experimental em fevereiro de 2003, o RFC 3465 mudou a unidade da conta. O texto simples, o registro RFC Editor, o Datatracker, o histórico, as referências, as citações posteriores e as erratas formam o registro verificável. A proposta modificava a lógica do RFC 2581, substituído depois pelo RFC 5681 no caminho normativo.

Os ACK atrasados permitidos pelo RFC 1122 podiam cobrir dois segmentos completos. Um emissor que contava mensagens via metade das chances de crescer. Se um ACK fosse perdido, a chance desaparecia mesmo quando o seguinte comprovava cumulativamente os mesmos dados.

Na direção oposta, ACK division repartia a confirmação de um segmento por vários ACK. Quando cada mensagem ganhava um incremento fixo, uma única quantidade de bytes cunhava crédito repetido. ABC exigia que todos os fragmentos somassem somente os bytes realmente novos.

Um livro de bytes no emissor

Em congestion avoidance, bytes_acked acumulava apenas bytes antes não confirmados. Quando chegava ao cwnd atual, o emissor subtraía esse valor e acrescentava um SMSS à janela. O alvo continuava próximo de um segmento por RTT, sem depender de quantas mensagens carregavam o avanço.

No slow start, a janela podia aumentar pelos bytes novos de um ACK, até L. Com L=1*SMSS, não era mais agressiva que a regra anterior, e essa forma foi recomendada. L=2*SMSS era permitido para experimentação e compensava a confirmação de dois segmentos; valores maiores eram proibidos.

O limite continha grandes ACK cumulativos e stretch ACK. Ainda assim, dois SMSS podiam ampliar micro-rajadas e aproximar o slow start de uma duplicação por volta. As simulações limitadas citadas pelo RFC mostraram mais perdas em alguns casos e justificaram experimentação, não uma afirmação de adoção ou justiça universal. O texto recomendou SACK do RFC 2018. O RFC 2861 tratou do problema relacionado de crédito de janela não usado em conexões limitadas pela aplicação.

Depois do RTO, o presente carregava o passado

Se um segmento anterior se perdia e os seguintes já estavam no receptor, retransmitir a lacuna depois do RTO podia produzir um ACK cumulativo atravessando vários segmentos. Todos eram recém-confirmados para o estado do emissor, mas talvez apenas a retransmissão tivesse saído da rede no RTT atual.

Por isso, o RFC 3465 exigia L=1*SMSS na recuperação por slow start após RTO. O RFC 2988, depois substituído pelo RFC 6298, dava o contexto do temporizador. O ACK era válido; sua evidência temporal é que não correspondia integralmente à capacidade recém-testada.

Mecanismos vizinhos tinham funções distintas. Limited Transmit no RFC 3042 permitia dados novos antes do terceiro ACK duplicado sob limites, mas não definia a conta ABC. O RFC 3449 analisava caminhos assimétricos, filtro e reconstrução de ACK, sem trocar a unidade do crédito do emissor. O catálogo do RFC 2525 oferece contexto de falhas de implementação, não prova de implantação.

As posteriores camadas de realidade de Heng Lu separam ACK observado, bytes novos, crédito admitido e pacotes emitidos. A prioridade do código em execução leva a examinar acumulador, limite, recuperação e rajada. São lentes editoriais posteriores, não uma atribuição de intenção privada.

O RFC 3465 tornou a conta mais resistente sem declarar todo byte confirmado como capacidade fresca. Recibos podiam ser divididos ou agrupados; o progresso subjacente não devia se multiplicar.

Fontes