Contar um pacote G.729 através de um túnel IPsec

A voz sobre IPsec é citada como uma taxa de bits do codec, e esse número está errado em todas as fronteiras excepto na do próprio codec. O áudio é 8 kbit/s, o pacote que o transporta é maior, o invólucro ESP é ainda maior, e a trama Ethernet acrescenta um enquadramento que nenhuma captura no túnel mostra. Contar um pacote a partir de um formato declarado é a única forma de saber o que a ligação física tem realmente de transportar. O percurso abaixo faz isso apenas para uma direção, e cada número aqui é aritmética, não medição.

Comece por uma decisão de packetização, não por um número de codec

Uma tabela de codec dá a taxa de carga útil e mais nada: o G.729 emite 8 kbit/s, que são 30 bytes de áudio cada 30 ms. Não diz nada sobre cabeçalhos, proteção ou enquadramento, e são esses três que dominam o resultado. O intervalo é uma decisão de política que ambas as pontas têm de aceitar, por isso escolha-o primeiro e declare-o, porque cada número posterior depende dessa única decisão.

Este exemplo usa 30 ms, pelo que a taxa de pacotes é 33.3 por segundo. Assume um cabeçalho RTP de 12 bytes, um cabeçalho UDP de 8 bytes e um cabeçalho IPv4 interno de 20 bytes sem opções, e nada de SRTP, compressão de cabeçalhos ou enchimento de confidencialidade do fluxo de tráfego; qualquer alteração desloca o orçamento com ela, por isso as premissas ficam ao lado da resposta.

Acrescente os cabeçalhos internos e depois o invólucro ESP

A aplicação envia carga útil mais RTP mais UDP mais IP, o que nesta packetização são 70 bytes. Esse fluxo interno dá 18.7 kbit/s, já mais do dobro da taxa do codec, porque são os cabeçalhos, e não o áudio, que ocupam a maior parte do pacote. Nenhum desses bytes é voz; são o preço de os endereçar e sequenciar. Uma captura feita acima do túnel mostra exactamente este número, e é o que as pessoas citam quando dizem que a chamada é pequena.

É também o número que nunca chega ao cabo. O modo túnel ESP acrescenta um SPI e um número de sequência de 8 bytes, um IV explícito de 8 bytes para AES-GCM, uma cauda de 2 bytes e uma etiqueta de autenticação de 16 bytes. A carga útil de 70 bytes mais a cauda chega a 72, o que já cumpre o alinhamento de quatro bytes, pelo que aqui não é necessário enchimento adicional.RFC 4106 fixa os tamanhos do IV e da etiqueta de GCM, e ambos pertencem à aritmética, não a uma nota de pé de página:

30  payload, G.729 at 30 ms
12  RTP
 8  UDP
20  inner IPv4
--
70  inner IP packet
 8  ESP SPI and sequence
 8  explicit IV
 2  pad length and next header
16  authentication tag
--
104 ESP packet

Acrescente os cabeçalhos externos que a passagem por NAT exige

Fora do invólucro ESP estão um cabeçalho IPv4 externo de 20 bytes e um cabeçalho UDP de 8 bytes para a passagem por NAT, pelo que o pacote passa a 132 bytes. A encapsulação UDP existe porque o pacote tem de sobreviver a um dispositivo de tradução entre os pares, e altera a forma externa sem tocar na carga protegida. A 33.3 pacotes por segundo, 132 bytes são cerca de 35.2 kbit/s, ou aproximadamente quatro vezes a taxa nominal do codec.

Nem a etiqueta nem o IV podem ser retirados da estimativa para a tornar menor, porque ambos fazem parte do que a ligação vai realmente transportar. Uma estimativa que os omite descreve um pacote que o receptor rejeitaria. O mesmo se aplica à cauda, que existe para marcar a fronteira da carga e o cabeçalho seguinte dentro da região protegida.

Nomeie a fronteira antes de citar o número

Um número de IP externo ainda exclui o enquadramento Ethernet. Uma ligação de acesso com ou sem etiqueta acrescenta um cabeçalho MAC de 14 bytes e uma sequência de verificação de trama de 4 bytes, tornando a trama em 150 bytes, que é o tamanho que uma porta de comutador conta. À mesma taxa de pacotes isso são 40 kbit/s, cinco vezes a taxa do codec, e a diferença não é desperdício mas o custo do transporte.

O número de 40 kbit/s ainda exclui o preâmbulo, o espaço entre tramas, as etiquetas VLAN, a encapsulação do operador, o RTCP, a sinalização e o áudio que viaja no sentido oposto. É uma estimativa por direção, não uma reserva de ligação, e citá-la como tal exagera o que a ligação tem de reservar num ponto enquanto o subestima noutro. Uma captura no anfitrião também pode perder o enquadramento que a ligação acrescenta, por isso a fronteira tem de ser nomeada ao lado do número, e por isso uma tabela de fronteiras é mais útil do que um único número de manchete. Reserve em separado para a direção que não contou.

Verifique a aritmética contra a interface

Antes de confiar na estimativa, compare-a com o que a interface relata para um número conhecido de pacotes. Capture na interface física e não no dispositivo do túnel, para que o enquadramento que está a tentar contabilizar seja incluído, e espere uma pequena discrepância em vez de uma correspondência perfeita.

sudo tcpdump -ni eth0 -c 50 'udp port 4500'
ip -s link show eth0

A captura confirma o tamanho do pacote externo, enquanto os contadores da interface mostram a taxa incluindo o enquadramento. Se os dois diferirem aproximadamente na tolerância Ethernet, a aritmética está certa e apenas a fronteira foi mal nomeada. Uma diferença muito maior do que um cabeçalho de trama aponta para outra coisa na ligação, como retransmissões ou outro fluxo que partilha a interface. Escreva o intervalo de packetização, o conjunto de proteção e a fronteira ao lado do número, porque uma estimativa sem esses três é citada como medição pela pessoa seguinte que a ler.