Por que o Jumbo Frames prejudica a latência?

Question

Recentemente eu tenho lido sobre quadros jumbo e fiquei confuso em alguns lugares. Tanto quanto eu entendo, há um limite inferior no tamanho do quadro Ethernet entre os pontos 'armazenar e encaminhar' (pontes de camada 2), pois os quadros precisam continuar sendo transmitidos enquanto alcança o destino para ativar a detecção de colisão. Esse limite não é afetado pela configuração do quadro jumbo.

Quadros jumbo aumentam o limite superior de tamanhos de quadros de cabeçalhos de 1500B + para valores maiores (por exemplo, cabeçalhos 4000B ou 9000B +).

Quadros maiores permitem menor sobrecarga, etc., mas há mais chances de que um único pacote seja corrompido em trânsito, além dos recursos de correção de erros. Se um pacote está corrompido, ele precisa ser retransmitido (inteiro), aumentando a latência. Além disso, a transmissão do pacote leva mais tempo, já que ele precisa ser (acredito) totalmente recebido antes da transferência para a CPU ou encaminhamento. No entanto, aplicativos sensíveis à latência geralmente usam UDP e tamanhos de pacotes personalizados para que eles não usem quadros jumbo (contanto que não façam a descoberta da MTU), portanto eles não devem ser afetados pelos Jumbo Frames, pois os quadros seriam menores.

Tendo em vista que os quadros jumbo prejudicam a latência em um grau mensurável, comecei a imaginar o que está causando esse efeito?

    

Answer 1

Aqui estão algumas maneiras pelas quais os quadros jumbo podem prejudicar a latência. Você já conhecia alguns deles:

1. Um quadro jumbo de 9kB é 6x maior que os maiores quadros Ethernet padrão, que são de 1500 bytes. Portanto, com a mesma taxa de erro de bit, os jumbo-frames têm uma chance 6 vezes maior de ter um erro e, quando ocorre um erro, todo o quadro 6x maior deve ser retransmitido.

2. O polinômio selecionado para o algoritmo CRC32 na sequência de verificação de quadros Ethernet (FCS) é ajustado para tamanhos de quadros de até 1500 bytes. É menos eficaz para tamanhos de quadros maiores, mas as pessoas de quadros gigantes não alteraram o polinômio. Portanto, é mais provável que os erros de bit nos quadros jumbo não sejam detectados na camada MAC e tenham que ser detectados posteriormente em uma camada superior (provavelmente a camada de aplicação no caso de UDP / IP), o que resulta em latência ainda maior antes de uma retransmissão é solicitado.

3. Se um pacote sensível à latência for enfileirado por trás de um quadro de tamanho total para acessar o meio, o tamanho médio será 6x maior para chegar ao meio se esse quadro de tamanho completo for um quadro jumbo de 9kB em vez de um frame padrão de 1500 Bytes.

4. Se um protocolo sensível à latência usasse quadros jumbo e tentasse preenchê-los para eficiência da largura de banda, a entrega dos primeiros bytes do quadro seria muito atrasada enquanto se esperava que os últimos bytes do quadro fossem construídos , antes que o quadro possa ser enviado para o fio. Para talvez um exemplo de pior caso, alguns codecs de voz de alta eficiência podem usar uma taxa de bits de 2kbps, portanto, um único quadro de 9k pode ter cerca de 36 segundos de fala. Imagine ter 36 segundos de atraso em uma chamada VoIP porque isso. É claro que, como você observou, seria tão insensato criar um protocolo sensível à latência dessa maneira, que isso parece óbvio demais para ser mencionado. No entanto, ainda é uma maneira que o uso de frames jumbo pode prejudicar a latência.

Por favor, note também que Path MTU Discovery é uma coisa da camada IP, então não é específico do TCP. Portanto, os protocolos baseados em UDP podem "se beneficiar" do Path MTU Discovery. Observe também que você não precisa fazer o PMTUD para saber o MTU do link local, portanto, se o host de envio estiver em uma Ethernet de quadro jumbo, ele terá seu MTU definido como (até) 9000 bytes, mesmo sem fazer PMTUD . Algo sobre a maneira como você escreveu sua pergunta me fez pensar que você pode não estar ciente disso.

P.S. Sim, os quadros precisam ser recebidos totalmente antes de continuar o manuseio, porque o FCS vem no final e é calculado em todo o quadro. Além disso, não há erro correção na Ethernet, apenas detecção.

    

Answer 2

Bem, acho que para um quadro grande ser transmitido intacto de ponta a ponta, todos os componentes no caminho devem suportar esse tamanho de quadro - isso significa que todos os roteadores e switches devem suportá-lo ou esse quadro será descartado. Espero que responda à sua pergunta.