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

La voz sobre IPsec se cita como una tasa de bits del códec, y esa cifra es errónea en todas las fronteras salvo en la del propio códec. El audio son 8 kbit/s, el paquete que lo transporta es mayor, la envoltura ESP es aún mayor, y la trama Ethernet añade un encuadre que ninguna captura en el túnel muestra. Contar un paquete a partir de un formato declarado es la única forma de saber qué debe transportar realmente el enlace físico. El recorrido de abajo lo hace solo para una dirección, y cada número aquí es aritmética, no medición.

Empieza por una decisión de paquetización, no por una cifra de códec

Una tabla de códec da la tasa de carga útil y nada más: G.729 emite 8 kbit/s, que son 30 bytes de audio cada 30 ms. No dice nada sobre cabeceras, protección ni encuadre, y esas tres cosas dominan el resultado. El intervalo es una decisión de política que ambos extremos deben acordar, así que elígelo primero y decláralo, porque cada número posterior depende de esa única decisión.

Este ejemplo usa 30 ms, así que la tasa de paquetes es 33.3 por segundo. Supone una cabecera RTP de 12 bytes, una cabecera UDP de 8 bytes y una cabecera IPv4 interna de 20 bytes sin opciones, y nada de SRTP, compresión de cabeceras ni relleno de confidencialidad del flujo de tráfico; cualquier cambio mueve el presupuesto con él, por eso los supuestos van junto a la respuesta.

Añade las cabeceras internas y luego la envoltura ESP

La aplicación envía carga útil más RTP más UDP más IP, que con esta paquetización son 70 bytes. Ese flujo interno sale a 18.7 kbit/s, ya más del doble de la tasa del códec, porque son las cabeceras, no el audio, las que ocupan la mayor parte del paquete. Ninguno de esos bytes es voz; son el precio de direccionarlo y secuenciarlo. Una captura tomada por encima del túnel muestra exactamente este número, y es el que la gente cita cuando dice que la llamada es pequeña.

Es también el número que nunca llega al cable. El modo túnel ESP añade un SPI y un número de secuencia de 8 bytes, un IV explícito de 8 bytes para AES-GCM, un tráiler de 2 bytes y una etiqueta de autenticación de 16 bytes. La carga útil de 70 bytes más el tráiler llega a 72, que ya cumple la alineación de cuatro bytes, así que aquí no hace falta relleno adicional.RFC 4106 fija los tamaños del IV y de la etiqueta de GCM, y ambos pertenecen a la aritmética, no a una nota al pie:

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

Añade las cabeceras externas que exige el tránsito por NAT

Fuera de la envoltura ESP están una cabecera IPv4 externa de 20 bytes y una cabecera UDP de 8 bytes para el tránsito por NAT, así que el paquete pasa a 132 bytes. La encapsulación UDP existe porque el paquete tiene que sobrevivir a un dispositivo de traducción entre los pares, y cambia la forma externa sin tocar la carga protegida. A 33.3 paquetes por segundo, 132 bytes son unos 35.2 kbit/s, o aproximadamente cuatro veces la tasa nominal del códec.

Ni la etiqueta ni el IV pueden quitarse de la estimación para hacerla más pequeña, porque ambos forman parte de lo que el enlace transportará realmente. Una estimación que los omite describe un paquete que el receptor rechazaría. Lo mismo vale para el tráiler, que existe para marcar la frontera de la carga y la cabecera siguiente dentro de la región protegida.

Nombra la frontera antes de citar el número

Una cifra de IP externa todavía excluye el encuadre Ethernet. Un enlace de acceso etiquetado o sin etiqueta añade una cabecera MAC de 14 bytes y una secuencia de verificación de trama de 4 bytes, lo que hace la trama de 150 bytes, que es el tamaño que cuenta un puerto de conmutador. A la misma tasa de paquetes eso son 40 kbit/s, cinco veces la tasa del códec, y la diferencia no es desperdicio sino el coste del transporte.

La cifra de 40 kbit/s todavía excluye el preámbulo, el espacio entre tramas, las etiquetas VLAN, la encapsulación del proveedor, RTCP, la señalización y el audio que viaja en la otra dirección. Es una estimación por dirección, no una reserva de enlace, y citarla como tal exagera lo que el enlace debe reservar en un punto mientras lo subestima en otro. Una captura en el host también puede perder el encuadre que añade el enlace, por eso hay que nombrar la frontera junto al número, y por eso una tabla de fronteras es más útil que una sola cifra de titular. Reserva por separado para la dirección que no contaste.

Comprueba la aritmética contra la interfaz

Antes de fiarte de la estimación, compárala con lo que la interfaz informa para un número conocido de paquetes. Captura en la interfaz física y no en el dispositivo del túnel, para que se incluya el encuadre que intentas contabilizar, y espera una pequeña discrepancia en lugar de una coincidencia perfecta.

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

La captura confirma el tamaño del paquete externo, mientras que los contadores de la interfaz muestran la tasa incluyendo el encuadre. Si los dos difieren en aproximadamente la tolerancia Ethernet, la aritmética es correcta y solo se etiquetó mal la frontera. Una diferencia mucho mayor que una cabecera de trama apunta a otra cosa en el enlace, como retransmisiones u otro flujo que comparte la interfaz. Escribe el intervalo de paquetización, el conjunto de protección y la frontera junto al número, porque una estimación sin esos tres la cita como medición la siguiente persona que la lea.