Eén G.729-pakket door een IPsec-tunnel tellen

Spraak over IPsec wordt als codec-bitrate genoemd, en dat getal is aan elke grens fout behalve aan die van de codec zelf. De audio is 8 kbit/s, het pakket dat hem draagt is groter, de ESP-envelop is nog groter, en het Ethernet-frame voegt framing toe die een opname op de tunnel nooit laat zien. Eén pakket tellen vanuit een opgegeven formaat is de enige manier om te weten wat de fysieke verbinding werkelijk moet dragen. De doorrekening hieronder doet dat voor één richting, en elk getal hier is rekenwerk, geen meting.

Begin bij een packetiseringskeuze, niet bij een codecgetal

Een codecktabel geeft de payloadsnelheid en niets anders: G.729 levert 8 kbit/s, dat is 30 byte audio per 30 ms. Hij zegt niets over headers, bescherming of framing, en die drie bepalen het resultaat. Het interval is een beleidskeuze waarover beide uiteinden het eens moeten zijn, dus kies het eerst en noem het, want elk later getal hangt van die ene beslissing af.

Dit voorbeeld gebruikt 30 ms, dus de pakketsnelheid is 33.3 per seconde. Het gaat uit van een RTP-header van 12 byte, een UDP-header van 8 byte en een binnenste IPv4-header van 20 byte zonder opties, en geen SRTP, headercompressie of opvulling voor vertrouwelijkheid van de verkeersstroom; elke wijziging verschuift het budget mee, daarom horen de aannames naast het antwoord.

Voeg de binnenste headers toe, dan de ESP-envelop

De applicatie verstuurt payload plus RTP plus UDP plus IP, wat bij deze packetisering 70 byte is. Die binnenste stroom komt uit op 18.7 kbit/s, al meer dan het dubbele van de codecsnelheid, omdat headers en niet audio het grootste deel van het pakket vormen. Geen van die bytes is stem; ze zijn de prijs van adressering en nummering. Een opname boven de tunnel toont precies dit getal, en dat is het getal dat mensen noemen als ze zeggen dat het gesprek klein is.

Het is ook het getal dat nooit de kabel haalt. ESP-tunnelmodus voegt een SPI en volgnummer van 8 byte toe, een expliciete IV van 8 byte voor AES-GCM, een trailer van 2 byte en een authenticatietag van 16 byte. De payload van 70 byte plus de trailer komt op 72, wat de uitlijning op vier byte al haalt, dus extra opvulling is hier niet nodig.RFC 4106 legt de maten van de GCM-IV en de tag vast, en beide horen in het rekenwerk, niet in een voetnoot:

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

Voeg de buitenste headers toe die NAT-passage vereist

Buiten de ESP-envelop zitten een buitenste IPv4-header van 20 byte en een UDP-header van 8 byte voor NAT-passage, dus het pakket wordt 132 byte. De UDP-inkapseling bestaat omdat het pakket een vertalend apparaat tussen de peers moet overleven, en ze verandert de buitenste vorm zonder de beschermde payload aan te raken. Bij 33.3 pakketten per seconde is 132 byte ongeveer 35.2 kbit/s, of ruwweg vier keer de nominale codecsnelheid.

Noch de tag noch de IV kan uit de schatting worden weggelaten om hem kleiner te maken, want beide horen bij wat de verbinding werkelijk draagt. Een schatting die ze weglaat, beschrijft een pakket dat de ontvanger zou weigeren. Hetzelfde geldt voor de trailer, die dient om de grens van de payload en de volgende header binnen het beschermde gebied te markeren.

Noem de grens voordat je het getal citeert

Een buitenste IP-getal sluit Ethernet-framing nog steeds uit. Een getagde of ongetagde toegangsverbinding voegt een MAC-header van 14 byte en een framecontrolesequentie van 4 byte toe, waardoor het frame 150 byte wordt, de maat die een switchpoort telt. Bij dezelfde pakketsnelheid is dat 40 kbit/s, vijf keer de codecsnelheid, en het verschil is geen verspilling maar de prijs van transport.

Het getal van 40 kbit/s sluit nog steeds de preamble, de interframetijd, VLAN-tags, provider-inkapseling, RTCP, signalering en de audio in de andere richting uit. Het is een schatting per richting, geen verbindingsreservering, en die als reservering citeren overschat wat de verbinding op één plek moet reserveren en onderschat het op een andere. Een opname op de host kan ook framing missen die de verbinding toevoegt, daarom moet de grens naast het getal worden genoemd, en daarom is een grenstabel nuttiger dan één enkel krantenkopgetal. Reserveer apart voor de richting die je niet hebt geteld.

Controleer het rekenwerk tegen de interface

Voordat je de schatting vertrouwt, vergelijk hem met wat de interface meldt voor een bekend aantal pakketten. Neem de opname op de fysieke interface en niet op het tunnelapparaat, zodat de framing die je probeert te verrekenen erin zit, en verwacht een kleine afwijking in plaats van een perfecte match.

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

De opname bevestigt de buitenste pakketgrootte, terwijl de interfacetellers de snelheid inclusief framing tonen. Als beide ongeveer de Ethernet-toeslag verschillen, klopt het rekenwerk en was alleen de grens verkeerd benoemd. Een verschil veel groter dan één frameheader wijst op iets anders op de verbinding, zoals hertransmissies of een andere stroom die de interface deelt. Schrijf het packetiseringsinterval, de beschermingssuite en de grens naast het getal, want een schatting zonder die drie wordt door de volgende lezer als meting geciteerd.