Stel een vertragingsbudget in voor realtimeverkeer over een VPN

Klachten over realtime-VPN hebben een deadline nodig om tegen te falen, en «lage latentie» is dat niet. Bepaal wat het gesprek of de externe sessie moet leveren en meet daarna het pad tegen die eis onder vermelde omstandigheden. Zonder een drempel voor late pakketten is elk resultaat betwistbaar. De toewijzing hieronder is een ontwerpbeslissing, en ze bestaat zodat de meting iets heeft om op te antwoorden.

Schrijf de deadline op voordat je een probe aanraakt

De deadline komt van de applicatie en haar gebruikers, niet van de marketingpagina van een leverancier. Een live spraakoproep, een sessie op een extern bureaublad en een nachtelijke back-up verdragen volledig verschillende wachttijden, en de storing die ertoe doet is meestal de staart en niet de mediaan. Schrijf het getal op samen met de werklast waartoe het behoort.

Verdeel het dan. Vastleggen en pakketteren gebruiken een deel van het budget, de toegangslink en de tunnel een ander deel, de de-jitterbuffer van de ontvanger houdt pakketten bewust tegen, en de applicatieverwerking neemt de rest. Die fasen benoemen houdt de tunnelversleuteling in verhouding in plaats van haar de standaardverdachte voor elk traag pakket te maken.

Definieer ten slotte het meetcontract in vier regels: eindpunten en richting, vorm van het verkeer, omstandigheden tijdens de run en de uitkomst die je rapporteert. Een rustige zondagsmeting en een belaste dinsdagsmeting beantwoorden verschillende vragen, dus vermeld welke je hebt verzameld. Als je niet alle vier regels kunt invullen, is de run niet klaar om te beginnen. Die checklist is ook wat twee rapporten maanden later vergelijkbaar maakt, wanneer niemand zich meer herinnert wat de link nog meer vervoerde.

Verdeel het budget over elke fase

De tabel is een planningshulpmiddel, geen vastgelegde data. Vul de eigenaar voor elke rij in vóór de eerste probe, want de eigenaar is degene die je belt wanneer die fase zijn aandeel overschrijdt.

Twee rijen verrassen mensen meestal. De ontvangerbuffer is geen fout wanneer hij vertraging toevoegt, want hij doet het werk waarvoor hij is geconfigureerd. En het aandeel van de tunnel is vaak kleiner dan de wachtrij ervoor, vooral op een uplink die tijdens uploads verzadigd raakt.

Als een fase geen eigenaar heeft, is het budget fictie. Wijs er een aan voordat je meet, anders besteed je de volgende vergadering aan ruzie over wiens getal verkeerd is.

Meet eenrichtingsvertraging met een eerlijke klok

Eenrichtingsvertraging is het getal waar de deadline om geeft, en het vereist gesynchroniseerde klokken aan beide uiteinden. De metriek voor eenrichtingsvertraging vereist dat je synchronisatiemethode, resolutie en geschatte afwijking naast het resultaat rapporteert. Twee niet-gesynchroniseerde hosts kunnen een zeer precies getal voor de verkeerde grootheid produceren.

Vang een paar honderd pakketten in plaats van een handvol, en noteer de klokstatus op hetzelfde moment:

$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3

Retourtijd is een aparte meting, niet twee eenrichtingswaarden bij elkaar opgeteld. Een RTT halveren veronderstelt symmetrische paden en symmetrische wachtrijen, en een tunnel over een mobiele uplink breekt beide aannames geregeld. Rapporteer RTT als RTT en houd die buiten het eenrichtingsbudget.

Rapporteer de staart en de late pakketten

Vat de verdeling samen: mediaan, 95e en 99e percentiel, slechtste geval, verlies en het aantal pakketten dat later aankwam dan de deadline toestaat. Het gemiddelde is van die getallen het minst bruikbaar voor een realtimewerklast, want een glad gemiddelde kan een staart verbergen die elk derde gesprek verpest.

Vertragingsvariatie voedt direct de ontvangerbuffer. Meer buffering verbergt variatie en voegt wachttijd toe, dus een stream kan stabiel lijken terwijl hij zijn deadline overschrijdt. Kies een formulering van de variatie, vermeld het interval waarover je hebt gemeten, en houd die consistent tussen runs.

Herhaal de run met representatief kruisverkeer. Een pad dat het budget haalt als het stil is en het mist tijdens een back-upvenster, heeft je iets nuttigs over planning verteld, wat geen enkele stille meting zou onthullen. Noteer de omstandigheden naast het resultaat, want de volgende ingenieur vergelijkt anders twee metingen die nooit vergelijkbaar waren.

Accepteer het ontwerp wanneer de gemeten staart binnen het budget past onder de werklast die je werkelijk draait, en verwerp het met de fase die overschreed genoemd in het rapport.