O que é Laminar?
O Laminar é uma nova estrutura para controle de congestionamento do TCP que separa a programação de transmissão, que determina com precisão quando os dados são enviados, do puro controle de congestionamento, que determina a quantidade total de dados enviados durante cada RTT.
O algoritmo padrão para programação de transmissão é uma implementação rigorosa do princípio de conservação de pacotes de Van Jacobson [Jacobson88]. Os dados que chegam ao receptor causam ACKs, que, por sua vez, fazem com que o remetente transmita uma quantidade equivalente de dados de volta à rede. A variável de estado principal está implícita na quantidade de dados e ACKs que circulam na rede. Esse estado é observado por meio de um estimador tcp_packets_in_flight() aprimorado (também conhecido como total_pipe). O total_pipe é baseado no "pipe", conforme descrito na RFC 3517, mas também inclui a quantidade de dados relatados pelo ACK atual e transmissões pendentes que passaram pelo controle de congestionamento, mas estão aguardando outros eventos, como TSO.
Uma nova variável, CCwin, é a variável principal de estado de controle de congestionamento. Os algoritmos de controle de congestionamento ajustam o CCwin para regular o nível de congestionamento geral ao longo do caminho. Embora o CCwin pareça cwnd, ele é sobrecarregado e usado por vários algoritmos (como supressão de burst) com metas diferentes e, às vezes, conflitantes.
Sempre que "total_pipe" é diferente de "CCwin", o algoritmo de programação de transmissão ajusta um pouco o número de segmentos enviados em resposta a cada ACK. Início lento e redução de taxa proporcional (PRR, na sigla em inglês) (uma substituição para a metade da taxa) são incorporados ao algoritmo de programação de transmissão.
A principal vantagem do framework Laminar é que, ao particionar o controle de congestionamento e a programação de transmissão em subsistemas separados, cada um está sujeito a restrições de design muito mais simples, facilitando o desenvolvimento de muitos novos algoritmos que não são viáveis com a organização anterior do código.
O framework Laminar muda a filosofia de design subjacente do controle de congestionamento TCP e tem amplas implicações, além do próprio patch. O objetivo desse patch é permitir que as pessoas experimentem o código, comentem e ajudem a descobrir casos específicos que possam ter sido ignorados. Além disso, o patch está incompleto, no sentido de que vários algoritmos ainda estão faltando, especificamente: algoritmos de controle de congestionamento diferentes de CUBIC e Reno, validação cwnd, métricas de destino etc. Seria muito ótimo se as pessoas ajudassem a refatorar alguns desses outros algoritmos.
A estrutura Laminar e a motivação dela são descritas mais detalhadamente em um rascunho da Internet, draft-mathis-tcpm-tcp-laminar.
Envie comentários e sugestões para mattmathis@google.com.
Este projeto faz parte dos esforços do Google para tornar a Web mais rápida com melhorias no protocolo.
Observações sobre implementação
O laminar é implementado principalmente em três funções (tcp_input.c):
Tcp_cong_avoid() e tcp_mult_decr() executam o controle de congestionamento do AIMD usando a variável de estado CCwin. Com exceção da ação desfazer, essas duas funções são os únicos lugares em que o comando CCwin muda. Ambas as funções invocam gerenciadores específicos do módulo de congestionamento.
Tcp_laminar_schedule() determina a quantidade de dados a ser enviada em resposta a cada ACK. Ela implementa a conservação de pacotes Van Jacobson, ajustada um pouco para cima ou para baixo para fazer com que tcp_packets_in_flight() converge para CCwin.
Há alterações importantes no estimador tcp_packets_in_flight() para torná-lo invariante na maioria dos eventos de protocolo. O aplicativo é interrompido, os ajustes em tcp_laminar_schedule() e as perdas reais de pacotes mudam tcp_packets_in_flight(), conforme necessário. O processamento de ACK, o TSO e a maioria dos outros eventos não fazem isso. Observe que, quando há perdas, o número real de pacotes em trânsito muda imediatamente, mas não é refletido no estimador tcp_packets_in_flight() até que o maquinário de retransmissão os marque como perdidos e incrementa o valor de Lost_out.
Receber o patch
Esse patch é contra o net-next de Dave Miller e se aplica de forma limpa ao 3.5-rc2.
NB: os outros módulos de controle de congestionamento que Reno e CUBIC não foram atualizados e não vão compilar. Se sua configuração criar outros módulos de controle de congestionamento, como vegas, escalonável, highspeed etc., eles precisarão ser desativados primeiro.