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

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 à 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 servidor de arquivos para arquivos na faixa de 10 a 100mb. Notei que, usando um initcwnd de 10, o tempo de transferência para esses arquivos é fortemente afetado pelo início lento do TCP, levando 3,5 segundos para carregar 10mb (velocidade máxima atingida: 3,3 MB / s) porque ele começa devagar e aumenta a velocidade. termina antes que a velocidade máxima seja atingida. Meu objetivo é ajustar os tempos mínimos de carregamento desses arquivos (para não obter maior taxa de transferência bruta ou menor latência de ida e volta, estou disposto a sacrificar os dois se isso diminuir o tempo real necessário para carregar um arquivo)

Então, tentei um cálculo simples para determinar qual deveria ser o initcwnd ideal, ignorando outras conexões e o possível impacto sobre os outros. O produto do atraso da largura de banda é de 200 Mbit / s * 50 ms = 10 Mbit ou 1.310.720 bytes. Considerando que o initcwnd está definido em unidades do MSS e assumindo que o MSS esteja em torno de 1400 bytes, será necessária uma configuração de: 1.310.720 / 1400 = 936

Esse valor está muito longe do padrão (10 * MSS no Linux, 64kb no Windows), portanto, não é uma boa ideia configurá-lo dessa maneira. Quais são as desvantagens esperadas de configurá-lo assim? Por exemplo:

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

Quais são as desvantagens esperadas de configurá-lo dessa maneira? Por exemplo:

Will it affect other users of the same network?

Alterar o initcwnd afetará:

• Os usuários do servidor com as configurações mudam
• SE esses usuários corresponderem à rota em que as alterações nas configurações estão definidas.

Could it create unacceptable congestion for other connections?

Certo.

Flood router-buffers somewhere on the path?

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

Increase the impact of small amounts of packet-loss?

Claro, pode fazer isso.

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

Também aumentará as chances de que um monte desses pacotes precise ser retransmitido porque um dos primeiros pacotes no burst será perdido.

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

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

Alterar initcwnd para (por exemplo) 10 significa que 10 pacotes desaparecerão imediatamente. Se todos eles atingirem o objetivo, você poderá acabar com uma janela muito maior na primeira RTT devido ao início lento (o aumento exponencial de cwnd). No entanto, com a perda de pacotes, o cwnd será reduzido pela metade e, como você está com 10 pacotes, terá uma quantidade considerável de retransmissões, para que você possa ter mais problemas do que pensa.

Se você quiser tentar algo mais agressivo e ser de alguma forma "rude" com outros usuários da Internet, poderá alterar o algoritmo de controle de congestionamento no servidor. Algoritmos diferentes tratam o cwnd de uma maneira diferente. Lembre-se de que isso afetará todos os usuários, a menos que o software do servidor altere essas conexões (o que duvido). O benefício aqui é que o algoritmo entrará em vigor 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, o cwnd (ou seja, tubo de gordura) duplicará a cada RTT. Com RTT = 50ms em um tubo de gordura, você ajustará 20 RTTs no primeiro segundo, o que significa que, com initcwnd = 2, você terminará com cwnd = 2 * 2 ^ 20 após 1 segundo, o que eu aposto que é mais do que você pode lidar com ;-)