Quais são as desvantagens possíveis para configurar um initcwnd (muito) grande para conexões de alta largura de banda?

Question

Eu tenho experimentado com os parâmetros TCP no Linux (com um kernel 3.5). Basicamente sobre esta conexão:

Servidor: uplink Gigabit no datacenter, a largura de banda real (devido ao compartilhamento de uplinks) é de cerca de 70 MB / s quando testada em outro datacenter.

Cliente: LAN local Gigabit conectada a fibra de 200mbit. A busca de um arquivo de teste atinge 20 MB / s.

Latência: cerca de 50 ms ida e volta.

O servidor remoto é usado como um servidor de arquivos para arquivos no intervalo de 10 a 100mb. Eu notei que usando um initcwnd de 10 o tempo de transferência para estes arquivos é strongmente afetado pelo TCP slow-start, levando 3.5 segundos para carregar 10mb (velocidade máxima atingida: 3.3 MB / s) porque ele começa lento e então aumenta termina antes que a velocidade máxima seja atingida. Meu objetivo é ajustar os tempos de carregamento mínimos desses arquivos (portanto, não a maior taxa de transferência bruta ou a menor latência de ida e volta, estou disposto a sacrificar ambos, se isso diminuir o tempo real necessário para carregar um arquivo)

Então eu tentei um cálculo simples para determinar qual deveria ser o initcwnd ideal, ignorando quaisquer outras conexões e possíveis impactos nos outros. O produto de atraso de largura de banda é de 200 Mbit / s * 50 ms = 10 Mbit ou 1.310.720 bytes. Considerando que o initcwnd é configurado em unidades do MSS e assumindo que o MSS tem cerca de 1400 bytes, isso requer uma configuração de: 1.310.720 / 1400 = 936

Este valor está muito longe do padrão (10 * MSS no Linux, 64kb no Windows), então não parece uma boa idéia configurá-lo assim. Quais são as desvantagens esperadas de configurá-lo assim? Por exemplo:

• Isso afetará outros usuários da mesma rede?
• Poderia criar um congestionamento inaceitável para outras conexões?
• Buffers de roteador de inundação em algum lugar no caminho?
• Aumentar o impacto de pequenas quantidades de perda de pacotes?

Answer 1

What are the expected downsides of configuring it like this? E.g:

Will it affect other users of the same network?

Alterar o initcwnd afetará:

• Usuários do servidor com as configurações mudam
• SE esses usuários corresponderem à rota em que a alteração de configurações está configurada.

Could it create unacceptable congestion for other connections?

Claro.

Flood router-buffers somewhere on the path?

Não é irrelevante, mas, a menos que sejam seus roteadores, eu me concentro nos problemas que estão mais próximos de você.

Increase the impact of small amounts of packet-loss?

Claro, isso pode ser feito.

O resultado é que isso aumentará o custo da perda de pacotes, intencional e não intencional. Seu servidor é mais simples para DOS por qualquer pessoa capaz de completar o handshake de três vias (quantidades significativas de dados para baixo investimento (quantidade de dados) em).

Também aumentará as chances de que muitos desses pacotes precisem ser retransmitidos porque um dos primeiros pacotes no burst será perdido.

    

Answer 2

Eu não acho que entendo completamente o que você está pedindo, então aqui está uma tentativa de responder:

Primeiro, o que você está tentando fazer só faz sentido no lado do envio e não no lado do recebimento. Ou seja você precisa estar mudando o servidor de arquivos e não o receptor. Supondo que é isso que você está fazendo:

Alterar o initcwnd para (por exemplo) 10 significa que 10 pacotes desaparecerão imediatamente. Se todos eles atingirem seu alvo, você pode acabar com uma janela muito maior no primeiro RTT por causa do slow-start (o aumento exponencial de cwnd). No entanto, após a perda de pacotes, o custo será reduzido pela metade e, como você está repleto de 10 pacotes, você terá uma quantidade considerável de retransmissões, de modo que poderá ter mais problemas do que imagina.

Se você quiser tentar algo mais agressivo e ser "rude" com outros usuários da Internet, em vez disso, pode alterar o algoritmo de controle de congestionamento no lado do servidor. Algoritmos diferentes lidam com o cwnd de uma maneira diferente. Lembre-se de que isso afetará todos os usuários, a menos que o software do servidor altere essa configuração por conexão (o que duvido muito). O benefício aqui é que o algoritmo estará ativo mesmo após a perda de pacotes enquanto o initcwnd não desempenhará muito papel.

/ proc / sys / net / ipv4 / tcp_congestion_control é onde você altera o algoritmo de controle de congestionamento.

FWIW para RTTs tão pequenos (50ms) e para arquivos médios ou grandes, o initcwnd não deve afetar muito sua velocidade média. Se não houver perda de pacotes então (isto é, tubo de gordura), o cwnd estará duplicando a cada RTT. Com RTT = 50ms em um tubo de gordura você vai caber 20 RTTs no primeiro segundo, o que significa que com initcwnd = 2 você vai acabar com cwnd = 2 * 2 ^ 20 após 1 segundo, o que eu aposto é mais do que você pode manusear; -)