Resumo

  • O draft-ietf-ccwg-ratelimited-increase-11 permite crescimento limitado de cwnd quando a aplicação ou o controle de fluxo do receptor, e não o congestionamento, restringe o envio.
  • maxFS liga esse crescimento ao maior FlightSize visto desde a última redução, mas não garante banda futura, novo crédito, pacing nem a chegada da próxima rajada.

Uma conexão pode ter cwnd para vinte segmentos enquanto a aplicação entrega apenas quatro. Se os quatro recebem ACK e não há perda aparente, a variável continua saudável. O espaço restante parece disponível.

Só parece: dezesseis segmentos nunca testaram o caminho.

Publicado em 6 de setembro, o draft-ietf-ccwg-ratelimited-increase-11 tenta uniformizar uma diferença entre TCP, QUIC, SCTP, DCCP e CUBIC. Há regras que impedem qualquer aumento quando o emissor não usa toda a janela. Há comportamentos que deixam a janela se afastar do volume realmente exercitado. A proposta da CCWG aceita um aumento sem tratar ausência de tráfego como prova de capacidade.

Rate-limited, nesse contexto, é o emissor que transmite abaixo do que o controle de congestionamento permitiria. A aplicação pode estar sem bytes ou o receptor pode restringir o crédito da conexão ou do stream. Assim, FlightSize—dados enviados e ainda não reconhecidos cumulativamente—fica abaixo de cwnd. A causa não precisa ser congestionamento.

O mecanismo conserva maxFS, maior FlightSize desde a redução mais recente da janela. Uma observação maior atualiza a variável; qualquer redução de cwnd a zera. O aumento seguinte deve ficar abaixo de limit(maxFS), isto é, o valor que o algoritmo alcançaria com os ACKs de uma janela bem-sucedida desse tamanho. Nos exemplos, o teto de Slow Start é 2*maxFS; o de Congestion Avoidance é maxFS+SMSS.

Isso permite aproveitar o crescimento normal de uma janela usada no RTT anterior, mesmo que a aplicação fique limitada logo depois. Ao mesmo tempo, impede a acumulação contínua de uma cwnd que a aplicação ou o receptor não utiliza. O voo reconhecido é evidência para um passo controlado. O espaço vazio não vira crédito acumulado.

O próprio texto reconhece que a memória envelhece. Sem outra forma de reduzir a janela, maxFS pode permanecer por tempo suficiente para deixar de refletir a rota atual. A referência a RFC 7661 é importante: Congestion Window Validation usa amostras pipeACK, volume reconhecido durante um intervalo de RTT, para separar capacidade recentemente validada de estado baseado em uma observação antiga. Trata-se de confiança com prazo, não de propriedade sobre banda futura.

Aplicação, receptor e rede continuam com controles distintos. A aplicação fornece a carga. O receptor abre crédito. O congestionamento limita a injeção conforme a evidência do caminho. Uma cwnd grande não cria demanda, não revoga back-pressure e não fixa topologia, filas, policers ou tráfego concorrente.

Pacing é outro registro. Ter permissão para manter mais bytes em voo não obriga o stack a enviá-los juntos. A proposta preserva o pacing, mas não prova que uma implementação o ativou, que escolheu o intervalo correto ou que a interface não agrupou pacotes após offload. É preciso observar configuração e tráfego.

Também é imprudente ampliar o significado de ACK. Ele confirma dados anteriores segundo a semântica do protocolo e atualiza recuperação e congestionamento. Não promete o próximo crédito, a mesma rota ou aceitação pela aplicação. Autenticar o ACK protege melhor a origem; não permite que ele fale pelo futuro.

Se aprovado, o documento atualizará os RFCs 4341, 5681, 9002, 9260 e 9438. Hoje é um Internet-Draft mutável, sem pedido de ação à IANA. Padronização, suporte no código, ativação operacional e resultado observado são recibos diferentes.

Fontes