Contar un paquete G.729 por un túnel IPsec

A voz sobre IPsec cítase como unha taxa de bits do códec, e esa cifra é errónea en todas as fronteiras agás na do propio códec. O audio son 8 kbit/s, o paquete que o transporta é maior, a envoltura ESP é aínda maior, e a trama Ethernet engade un enmarcado que ningunha captura no túnel mostra. Contar un paquete a partir dun formato declarado é a única forma de saber que debe transportar realmente a ligazón física. O percorrido de abaixo faino só para unha dirección, e cada número aquí é aritmética, non medida.

Comeza por unha decisión de paquetización, non por unha cifra de códec

Unha táboa de códec dá a taxa de carga útil e nada máis: G.729 emite 8 kbit/s, que son 30 bytes de audio cada 30 ms. Non di nada sobre cabeceiras, protección nin enmarcado, e esas tres cousas dominan o resultado. O intervalo é unha decisión de política que ambos extremos deben acordar, así que escolle primeiro e declárao, porque cada número posterior depende desa única decisión.

Este exemplo usa 30 ms, así que a taxa de paquetes é 33.3 por segundo. Supón unha cabeceira RTP de 12 bytes, unha cabeceira UDP de 8 bytes e unha cabeceira IPv4 interna de 20 bytes sen opcións, e nada de SRTP, compresión de cabeceiras nin recheo de confidencialidade do fluxo de tráfico; calquera cambio move o orzamento con el, por iso as suposicións van xunto á resposta.

Engade as cabeceiras internas e despois a envoltura ESP

A aplicación envía carga útil máis RTP máis UDP máis IP, que con esta paquetización son 70 bytes. Ese fluxo interno sae a 18.7 kbit/s, xa máis do dobre da taxa do códec, porque son as cabeceiras, non o audio, as que ocupan a maior parte do paquete. Ningún deses bytes é voz; son o prezo do enderezo e da secuenciación. Unha captura tomada por riba do túnel mostra exactamente este número, e é o que a xente cita cando di que a chamada é pequena.

É tamén o número que nunca chega ao cable. O modo túnel ESP engade un SPI e un número de secuencia de 8 bytes, un IV explícito de 8 bytes para AES-GCM, un tráiler de 2 bytes e unha etiqueta de autenticación de 16 bytes. A carga útil de 70 bytes máis o tráiler chega a 72, que xa cumpre a aliñación de catro bytes, así que aquí non fai falta recheo adicional.RFC 4106 fixa os tamaños do IV e da etiqueta de GCM, e ambos pertencen á aritmética, non a unha nota ao pé:

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

Engade as cabeceiras externas que esixe o tránsito por NAT

Fóra da envoltura ESP están unha cabeceira IPv4 externa de 20 bytes e unha cabeceira UDP de 8 bytes para o tránsito por NAT, así que o paquete pasa a 132 bytes. A encapsulación UDP existe porque o paquete ten que sobrevivir a un dispositivo de tradución entre os pares, e cambia a forma externa sen tocar a carga protexida. A 33.3 paquetes por segundo, 132 bytes son uns 35.2 kbit/s, ou aproximadamente catro veces a taxa nominal do códec.

Nin a etiqueta nin o IV poden quitarse da estimación para facela máis pequena, porque ambos forman parte do que a ligazón transportará realmente. Unha estimación que os omite describe un paquete que o receptor rexeitaría. O mesmo vale para o tráiler, que existe para marcar a fronteira da carga e a cabeceira seguinte dentro da rexión protexida.

Nomea a fronteira antes de citar o número

Unha cifra de IP externa aínda exclúe o enmarcado Ethernet. Unha ligazón de acceso etiquetada ou sen etiqueta engade unha cabeceira MAC de 14 bytes e unha secuencia de verificación de trama de 4 bytes, o que fai a trama de 150 bytes, que é o tamaño que conta un porto de conmutador. Á mesma taxa de paquetes iso son 40 kbit/s, cinco veces a taxa do códec, e a diferenza non é desperdicio senón o custo do transporte.

A cifra de 40 kbit/s aínda exclúe o preámbulo, o espazo entre tramas, as etiquetas VLAN, a encapsulación do provedor, RTCP, a sinalización e o audio que viaxa na outra dirección. É unha estimación por dirección, non unha reserva de ligazón, e citala como tal esaxera o que a ligazón debe reservar nun punto mentres o subestima noutro. Unha captura no equipo tamén pode perder o enmarcado que engade a ligazón, por iso hai que nomear a fronteira xunto ao número, e por iso unha táboa de fronteiras é máis útil que unha soa cifra de titular. Reserva por separado para a dirección que non contaches.

Comproba a aritmética contra a interface

Antes de confiar na estimación, compáraa co que a interface informa para un número coñecido de paquetes. Captura na interface física e non no dispositivo do túnel, para que se inclúa o enmarcado que intentas contabilizar, e espera unha pequena discrepancia en lugar dunha coincidencia perfecta.

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

A captura confirma o tamaño do paquete externo, mentres que os contadores da interface mostran a taxa incluíndo o enmarcado. Se os dous difiren aproximadamente na tolerancia Ethernet, a aritmética é correcta e só se etiquetou mal a fronteira. Unha diferenza moito maior ca unha cabeceira de trama apunta a outra cousa na ligazón, como retransmisións ou outro fluxo que comparte a interface. Escribe o intervalo de paquetización, o conxunto de protección e a fronteira xunto ao número, porque unha estimación sen eses tres citaa como medida a seguinte persoa que a lea.