Comptar un paquet G.729 per un túnel IPsec

La veu sobre IPsec es cita com a bitrate del còdec, i aquesta xifra és errònia a totes les fronteres excepte a la del mateix còdec. L'àudio és de 8 kbit/s, el paquet que el porta és més gran, l'embolcall ESP encara és més gran, i la trama Ethernet afegeix un emmarcat que cap captura al túnel no mostra. Comptar un paquet a partir d'un format declarat és l'única manera d'aprendre què ha de portar realment l'enllaç físic. El recorregut de sota ho fa només per a una direcció, i cada número d'aquí és aritmètica, no mesura.

Comenceu per una decisió de paquetització, no per una xifra de còdec

Un gràfic de còdec dóna la taxa de càrrega útil i res més: G.729 emet 8 kbit/s, que són 30 bytes d'àudio cada 30 ms. No diu res sobre capçaleres, protecció o emmarcat, i aquestes tres coses dominen el resultat. L'interval és una decisió de política que els dos extrems han d'acordar, així que trieu-lo primer i declareu-lo, perquè cada número posterior depèn d'aquesta única decisió.

Aquest exemple fa servir 30 ms, així que la taxa de paquets és de 33.3 per segon. Assumeix una capçalera RTP de 12 bytes, una capçalera UDP de 8 bytes i una capçalera IPv4 interna de 20 bytes sense opcions, i cap SRTP, compressió de capçaleres ni farciment de confidencialitat del flux de trànsit; qualsevol canvi mou el pressupost amb ell, i per això les suposicions van al costat de la resposta.

Afegiu les capçaleres internes i després l'embolcall ESP

L'aplicació envia càrrega útil més RTP més UDP més IP, que amb aquesta paquetització són 70 bytes. Aquest flux intern surt a 18.7 kbit/s, ja més del doble de la taxa del còdec, perquè són les capçaleres, no l'àudio, les que ocupen la major part del paquet. Cap d'aquests bytes és veu; són el preu d'adreçar-lo i seqüenciar-lo. Una captura feta per sobre del túnel mostra exactament aquest número, i és el que la gent cita quan diu que la trucada és petita.

És també el número que mai arriba al cable. El mode túnel ESP afegeix un SPI i un número de seqüència de 8 bytes, un IV explícit de 8 bytes per a AES-GCM, un tràiler de 2 bytes i una etiqueta d'autenticació de 16 bytes. La càrrega útil de 70 bytes més el tràiler arriba a 72, que ja compleix l'alineació de quatre bytes, així que aquí no cal farciment addicional.RFC 4106 fixa les mides de l'IV i de l'etiqueta de GCM, i totes dues pertanyen a l'aritmètica, no a una nota al peu:

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

Afegiu les capçaleres externes que exigeix el pas per NAT

Fora de l'embolcall ESP hi ha una capçalera IPv4 externa de 20 bytes i una capçalera UDP de 8 bytes per al pas per NAT, així que el paquet esdevé 132 bytes. L'encapsulació UDP existeix perquè el paquet ha de sobreviure a un dispositiu de traducció entre els parells, i canvia la forma externa sense tocar la càrrega protegida. A 33.3 paquets per segon, 132 bytes són uns 35.2 kbit/s, o aproximadament quatre vegades la taxa nominal del còdec.

Ni l'etiqueta ni l'IV no es poden treure de l'estimació per fer-la més petita, perquè tots dos formen part del que l'enllaç portarà realment. Una estimació que els omet descriu un paquet que el receptor rebutjaria. El mateix val per al tràiler, que existeix per marcar la frontera de la càrrega i la capçalera següent dins de la regió protegida.

Anomeneu la frontera abans de citar el número

Una xifra d'IP extern encara exclou l'emmarcat Ethernet. Un enllaç d'accés amb etiqueta o sense afegeix una capçalera MAC de 14 bytes i una seqüència de verificació de trama de 4 bytes, fent la trama de 150 bytes, que és la mida que compta un port de commutador. A la mateixa taxa de paquets això són 40 kbit/s, cinc vegades la taxa del còdec, i la diferència no és malbaratament sinó el cost del transport.

La xifra de 40 kbit/s encara exclou el preàmbul, l'espai entre trames, les etiquetes VLAN, l'encapsulació del proveïdor, RTCP, la senyalització i l'àudio que viatja en l'altra direcció. És una estimació per direcció, no una reserva d'enllaç, i citar-la com a tal exagera el que l'enllaç ha de reservar en un lloc mentre ho subestima en un altre. Una captura a l'amfitrió també pot perdre l'emmarcat que afegeix l'enllaç, i per això cal anomenar la frontera al costat del número, i per això una taula de fronteres és més útil que una sola xifra principal. Reserveu per separat la direcció que no heu comptat.

Comproveu l'aritmètica contra la interfície

Abans de confiar en l'estimació, compareu-la amb el que la interfície informa per a un nombre conegut de paquets. Captureu a la interfície física i no al dispositiu del túnel, perquè hi sigui inclòs l'emmarcat que intenteu comptabilitzar, i espereu una petita discrepància en lloc d'una coincidència perfecta.

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

La captura confirma la mida del paquet extern, mentre que els comptadors de la interfície mostren la taxa incloent-hi l'emmarcat. Si les dues difereixen aproximadament en la tolerància Ethernet, l'aritmètica és correcta i només s'ha etiquetat malament la frontera. Una diferència molt més gran que una capçalera de trama apunta a una altra cosa a l'enllaç, com ara retransmissions o un altre flux que comparteix la interfície. Escriviu l'interval de paquetització, el conjunt de protecció i la frontera al costat del número, perquè una estimació sense aquests tres la cita com a mesura la propera persona que la llegeix.