Resumo

  • O método aprovado limita o crescimento da janela de um emissor contido pela aplicação ou pelo receptor com base no maior FlightSize efetivamente usado desde a última redução de cwnd.
  • Um ACK válido comprova a chegada de dados enviados; não comprova a segurança de espaço ocioso que nunca foi colocado no caminho.

A conta chegou antes da rede

O exemplo do documento começa com uma janela inicial de dez segmentos. O emissor manda todos e para. Sem perdas e com um ACK por segmento, o slow start aumenta cwnd de dez para vinte.

A aplicação então fornece quatro segmentos. Eles também chegam e são confirmados. Sem um teto, os quatro ACKs elevam cwnd para vinte e quatro. Porém, o maior voo observado em um RTT continua sendo dez.

Os ACKs estão corretos. O erro é transformar o sucesso de um voo pequeno e restrito em autorização para uma parcela de janela nunca exercida.

É um cálculo ilustrativo, não um incidente. ACK atrasado, contabilidade por bytes, pacing e perda foram retirados para expor a pergunta central: qual evidência autoriza um host a ampliar a quantidade de dados não confirmados que pode lançar na rede?

O estado documental não encerra a prova

O anúncio de 24 de agosto, às 17h57 UTC, aprova a revisão 10 de “Increase of the Congestion Window when the Sender Is Rate-Limited” como Proposed Standard. O texto do Congestion Control Working Group atualiza DCCP CCID 2, TCP, QUIC, SCTP e CUBIC.

No congelamento de 28 de agosto, o Datatracker ainda mostrava Active Internet-Draft na fila do RFC Editor, aguardando contribuição dos autores. Não há ação de IANA. Aprovação, número de RFC, incorporação em software, ativação e resultado operacional são estados diferentes.

O anúncio registra várias implementações e uma linhagem Linux desde a versão 3.16. Isso demonstra experiência prática, mas não identifica a versão, configuração ou telemetria de uma frota específica.

Descobrir quem limitou a emissão

O controle de congestionamento pode permitir mais envio do que ocorre. A aplicação pode não ter dados. O receptor pode reduzir rwnd ou o crédito de conexão e stream QUIC. Um pacer pode espaçar partidas.

O texto chama de cwnd-limited o fluxo que consome a permissão. Seguindo a RFC 7661, rate-limited é o fluxo que usa no máximo metade de cwnd e permanece em fase não validada.

As decisões pertencem a superfícies distintas. Aplicação fornece bytes; receptor concede crédito; transporte calcula a janela; pacing define tempo; o caminho devolve perda, ECN, latência e entrega. Um rótulo genérico de subutilização não identifica quem fechou a torneira.

Cwnd é uma permissão local, não uma medição de banda. Ela limita dados não confirmados em voo, mas não garante capacidade futura, prontidão do receptor ou permanência da rota.

maxFS ancora a permissão no uso

A nova regra mantém maxFS, o maior FlightSize desde a última queda de cwnd. O valor começa na janela inicial e passa a ser o máximo entre si e cada voo observado.

Toda redução de cwnd zera maxFS; o próximo voo estabelece nova base. Perda, ECN ou outra redução encerram também a autoridade do máximo anterior.

Quando FlightSize < cwnd, ACKs ainda podem conduzir aumento, mas o resultado não ultrapassa limit(maxFS). Esse valor é o que o algoritmo produziria depois de enviar e confirmar uma janela completa do tamanho do maior voo exercido.

No slow start da RFC 5681, o exemplo usa duas vezes maxFS. Em congestion avoidance, maxFS + SMSS. O método não despreza os ACKs; delimita o que podem autorizar.

No caso dez mais quatro, a primeira rodada leva cwnd a vinte. Os quatro ACKs seguintes continuam válidos, mas não rompem o teto. Um voo posterior acima de dez desloca maxFS e dá base real para uma cota maior.

Um princípio comum não produz código uniforme

O TCP padrão não tinha limite explícito nessa condição. DCCP CCID 2 podia crescer sem estar contido por cwnd. QUIC recomendava não crescer com janela subutilizada. SCTP e CUBIC também tinham barreiras mais conservadoras em partes do algoritmo.

O novo documento cria um meio-termo: mais flexível do que congelar, mais rigoroso do que crescer sem teto. Controles baseados em taxa devem manter o máximo sustentado abaixo do que a regra de cwnd permitiria. Pacing continua válido se não infla os bytes em voo por RTT.

Em BBR e outros híbridos, estimativa de taxa, pacing rate, cwnd e amostras limitadas pela aplicação precisam de observação separada. A norma unifica o limite probatório, não toda implementação.

Uma medida antiga pode sobreviver ao caminho

O próprio texto alerta: sem redução de cwnd, maxFS pode envelhecer e deixar de representar o caminho atual. Uma troca móvel, de rota, túnel ou política de fila não garante reset.

A RFC 7661 aborda o problema relacionado de validar uma janela maior do que o voo recente e define pipeACK. São mecanismos complementares. Rate-Limited Increase governa o aumento; Congestion Window Validation trata a janela subutilizada e sua reação à congestão.

Guardar um máximo evita reaprender depois de cada pausa da aplicação. Guardá-lo sem data, caminho e histórico de redução cria memória sem procedência.

ACK autêntico continua sendo evidência estreita

O controle depende de confirmações apropriadas. A proteção contra ataque varia com o transporte. Mesmo um ACK autêntico confirma apenas dados específicos; não certifica capacidade ociosa, RTT futuro, equidade ou rota estável.

Aceitação do ACK, envio confirmado e crescimento autorizado devem aparecer como três decisões. O Linux atual verifica se Reno e CUBIC estão cwnd-limited antes de crescer. É uma superfície pública de código em execução, não prova sobre um serviço nomeado.

A cadeia operacional reúne transporte e build, fila da aplicação, crédito do receptor, pacing, cwnd, FlightSize, maxFS, janela inicial, ssthresh, bytes confirmados, redução por perda ou ECN, teto calculado, caminho e resultado após a retomada. A norma fornece a regra mínima; medição local demonstra a segurança.

Fontes