Evaluatie van de TCP Prague-implementatie
Het merendeel van het internetverkeer is capacity-seeking. Dit betekent dat deze datastromen hun bandbreedte maximaliseren binnen de beschikbare capaciteit, inclusief het benutten van grote buffers die bedoeld zijn om pieken op te vangen. Dit leidt als gevolg tot queuing delay. Aangezien steeds meer internetapplicaties lage latency vereisen, is dit een probleem dat naar verwachting alleen maar zal toenemen. Het gaat daarbij niet alleen om videobellen en e-sports, maar ook om remote desktops, videostreaming, op afstand bestuurde apparaten en tal van andere technologieën die momenteel nog niet goed haalbaar zijn vanwege vertragingen die vaak oplopen tot tientallen milliseconden of meer. Met de huidige technologieën neemt, zelfs in goed geconfigureerde netwerken, de latency doorgaans toe zodra er langdurige datastromen aanwezig zijn, doordat buffers vollopen en de gebruikerservaring verslechtert.
Om dit probleem en de bijbehorende uitdagingen aan te pakken, is een nieuwe architectuur ontwikkeld met bijbehorende technologieën die lage latency, minimale packet loss en schaalbare throughput bieden via de L4S internetstandaarden. De L4S-architectuur is bedoeld om een incrementele uitrol van schaalbare congestion control-mechanismen mogelijk te maken. Scalable Congestion Control (CC), zoals Data Center TCP (DCTCP), dat al wordt toegepast binnen datacenters, en Immediate Active Queue Management (AQM) zijn hiervoor opnieuw ingezet.
DCTCP en het concept van schaalbaarheid
DCTCP is schaalbaar in tegenstelling tot “niet-schaalbare” klassieke congestion control-mechanismen zoals Cubic, Reno en BBR. Een congestion controller is schaalbaar wanneer de frequentie van congestion-signals per round trip meegroeit met veranderingen in het bandwidth-delay product (BDP of window). Naarmate de throughput toeneemt, neemt de hersteltijd van DCTCP na packet loss niet toe dankzij het multiplicatieve herstelmechanisme. Dit staat in contrast met klassieke congestion control, die herstelt via een additief proces waarbij per positieve ACK één pakket aan het congestion window wordt toegevoegd. Hierdoor kost het klassieke CC-mechanismen meer tijd om te herstellen bij hogere throughput. Hoewel DCTCP al in gebruik is als schaalbare CC, kan het niet op het publieke internet worden uitgerold omdat het klassiek verkeer bij gedeelde bottlenecks zou verdringen en bovendien securityrisico’s met zich meebrengt.
De Prague requirements en L4S-standaardisatie
Hoewel deze nieuwe generatie congestion control-mechanismen aanzienlijke voordelen biedt, is een onmiddellijke overstap niet haalbaar. Dergelijke CC’s moeten kunnen samenwerken met oudere varianten zonder een oneerlijk voordeel te behalen. Doordat schaalbare TCP-varianten fijnmaziger congestion control toepassen, reageren zij minder agressief op congestion-signals en zouden zij oudere varianten zoals Reno en Cubic overvleugelen. Om hiervoor een kader te bieden, is een set eisen opgesteld, bekend als de “Prague requirements”. Deze beschrijven essentiële functionaliteiten die nodig zijn om klassieke congestion control te verbeteren en de valkuilen van DCTCP te vermijden.
De L4S-architectuur waarop de Prague requirements zijn gebaseerd, bevindt zich in het standaardisatieproces bij de IETF. Nu er implementaties worden uitgerold die stellen aan deze eisen te voldoen en consistente lage latency en volledige throughputbenutting te realiseren, is er behoefte aan een diepgaande, vergelijkende evaluatie. Voor zover bekend bij de auteurs is er nog geen onderlinge evaluatie uitgevoerd, noch een vergelijking met klassieke congestion control. Een dergelijke analyse is noodzakelijk om fairness te waarborgen, coexistence-problemen tussen schaalbaar en niet-schaalbaar TCP-verkeer aan te pakken en gelijke toegang tot het internet te garanderen.
Onderzoeksdoel
Dit onderzoek richtte zich daarom op de evaluatie van TCP Prague-implementaties met de volgende onderzoeksvraag:
“Zijn de huidige TCP Prague-implementaties compliant met de standaard?”
