Os protocolos de tunelamento, como o GTP, são um gargalo limitando a taxa de transferência?

Question

Quando protocolos de encapsulamento como o IPSec (no modo de encapsulamento) ou o GTP estão em uso, eles colocam vários fluxos de IP em um fluxo. Como existe apenas um fluxo, como aumentamos o rendimento? Atribuir mais núcleos de processador não ajudará, já que os pacotes de um fluxo podem ir para apenas um núcleo. Existe alguma maneira de contornar este problema? No meu caso, o problema é com o GTP. Os eNodeBs colocam todos os fluxos IP dos UEs em um túnel GTP para o qual o 5-tuple será o mesmo. Como temos apenas 5 a 10 eNodeBs, isso resulta no mesmo número de fluxos IP. Assim, a utilização do núcleo torna-se muito desigual, com núcleos sendo utilizados > 80% e alguns com < 10% de uso. Cada fluxo é processado por um único núcleo para que não haja reordenamento de pacotes. Como milhares de fluxos IP são tunelados em apenas 5 a 10 fluxos IP, a aleatoriedade da função hash RSS fica irregular, resultando em alguns núcleos ficando sobrecarregados, enquanto alguns ainda estão ociosos.

Seria correto chamá-lo de um problema inerente a qualquer protocolo de tunelamento? Qualquer maneira de contornar isso? Além disso, qual é o throughput máximo atingível com um único fluxo? Eu estou apenas procurando por algum valor de referência em qualquer hardware aqui. Você pode até compartilhar os resultados do IPSec no modo de túnel. Quanta taxa de transferência você pode obter com um único túnel IPSec e o que os administradores normalmente fazem para aumentar a taxa de transferência?

    

Answer 1

O problema que você descreve não é uma questão inerente aos protocolos de encapsulamento. Pelo contrário, está mais relacionado à presença de criptografia do que ao tunelamento.

Há precedência para implementações de ECMP que inspecionam campos em camadas de protocolo mais altas do que as que estão em operação. Por exemplo, o ECMP operando na camada IP geralmente inspeciona números de porta UDP e TCP. Não seria diferente para uma implementação do ECMP inspecionar os endereços IP no cabeçalho IP interno do pacote tunnelled.

No entanto, devido à criptografia, essas informações não estão prontamente disponíveis sem descriptografar o pacote. E ser capaz de distinguir os fluxos sem conhecer a chave de criptografia normalmente seria considerado uma falha de segurança no algoritmo de criptografia. Este é um ponto importante a ter em conta, pois poderá ter de fazer um compromisso entre desempenho e segurança.

Possíveis soluções que posso pensar em incluir:

• Copie o rótulo de fluxo do cabeçalho IP interno para o cabeçalho IP externo no momento da criptografia. Isso obviamente vazará informações sobre o conteúdo do rótulo de fluxo.
• Configure vários túneis e execute o ECMP nos túneis. A implementação do ECMP na extremidade de envio da conexão tentará espalhar o tráfego uniformemente pelos túneis. No entanto, dependendo dos padrões de tráfego, pode não ser possível distribuir o tráfego uniformemente pelos túneis. Essa distribuição desigual entre os túneis é problemática não apenas porque pode causar uma utilização abaixo do ideal da rede subjacente, mas também porque vaza algumas informações sobre as características do tráfego não criptografado. No entanto, o vazamento nesse caso será muito menos significativo do que a exposição de partes do cabeçalho IP interno.

• Permite a descriptografia de pacotes arbitrários em paralelo, mas os coloca de volta na ordem original após a descriptografia. Uma implementação muito simples tem um thread responsável por despachar pacotes de maneira round-robin para um número de threads de decriptação. Após a descriptografia, outro thread pegará os pacotes descriptografados em um modo round-robin a partir dos threads de descriptografia, colocando-os de volta em sua ordem original.

  Essa abordagem só é possível se você considerar todos os seus encadeamentos como um único domínio de falha e a comunicação entre os encadeamentos não estiver sujeita à perda de pacotes. Declarado diferentemente usando essa abordagem para distribuir pacotes no round-robin entre diferentes dispositivos de rede não funcionaria.

• Descriptografe para um formato intermediário não criptografado que contenha a carga útil não criptografada e o número de sequência IPSec. A descriptografia pode ser feita em paralelo, após o qual os pacotes são passados para um componente que armazena em buffer um número limitado de pacotes e tenta trazer os pacotes de volta na ordem original com base no melhor esforço.

• Redesenhe os protocolos de camada superior para serem mais tolerantes ao reordenamento.

Answer 2

A rede pode ser um gargalo com ou sem um protocolo de encapsulamento. Em algum ponto, a taxa de transferência do backplane não pode acompanhar a taxa de transferência da rede. Normalmente, todo o tráfego é roteado através de uma única interface de rede, que agrega várias conexões.

Deve ser possível que a criptografia / descriptografia de fluxos individuais seja feita em paralelo. Além do tráfego de backplane adicional, o uso de um túnel criptografado não deve limitar a rede de forma significativa com múltiplos fluxos de rede.

Os aceleradores de criptografia de hardware podem ajudar se a sobrecarga de criptografia for um problema. No entanto, parece que você tem CPU suficiente que não deve ser um problema.

Se o seu aplicativo estiver saturando o link da rede, talvez seja possível unir várias interfaces para aumentar o rendimento. O switch ao qual seu servidor está conectado precisará suportar a vinculação de canal.

Usar uma placa de rede mais rápida pode ajudar, mas você alcançará uma velocidade que o seu backplane não conseguirá acompanhar.

Os dispositivos de rede também têm limites de capacidade e seus requisitos excedem essa capacidade. Nesse caso, sua infraestrutura de rede se torna o gargalo.

Devido ao cache de memória, pode não fazer sentido equilibrar a carga entre várias CPUs. Muitas vezes, uma aplicação será executada mais rapidamente se continuar a rodar em uma única CPU, do que se ela for freqüentemente programada em CPUs diferentes.