Onze pakketten zijn te klein!
▼ Zoals genoegzaam bekend, communiceren we over het internet in pakketten. Tekst, plaatjes, telefonie, video, data... alles wordt in stukken gehakt en als IP-pakketten verstuurd. Pakketten die nauwelijks groter zijn dan 25 jaar geleden, waardoor routers, switches en computers duurder en ingewikkelder zijn en meer stroom gebruiken dan nodig.
Het probleem
Mijn eerste inbelverbinding naar XS4ALL 20 jaar geleden gebruikte pakketten van misschien 576 bytes. Daar past de tekst van dit stukje tot nu toe precies in. Twee jaar later was ik de apetrotse eigenaar van een ISDN-lijn, die ruim twee keer zo snel was als mijn modemverbinding, en pakketten van 1500 bytes gebruikte. Niet geheel toevallig is de maximale pakketgrootte van de originele 10 megabit Ethernet-standaard ook 1500 bytes. Om de volle 10 Mbps te gebruiken moet je dus 813 pakketten per seconde versturen.
En toen kregen we Fast Ethernet, met een snelheid bandbreedte van maar liefst 100 Mbps. Het mooie aan Fast Ethernet was dat je je oude switch of hub verving door een nieuw, supersnel exemplaar, dat op de poorten waar een Fast Ethernet-systeem aan hing 100 Mbps runde, en op de overige poorten gewoon 10 Mbps. Dit betekende wel dat Fast Ethernet dezelfde maximale pakketgrootte moest hebben als 10 Mbps Ethernet, anders zou een oude NE2000 Ethernetkaart de pakketten van een bloedsnelle 3Com Fast Ethernet-kaart niet kunnen ontvangen. Dus om de volle 100 Mbps te kunnen gebruiken moet je ruim 8000 pakketten per seconde versturen.
En toen kwam Gigabit Ethernet, wat nog steeds compatibel moest zijn met die oude NE2000 en de ook al niet meer zo nieuwe 3Com-kaart: 80.000 pakketten per seconde (PPS). En toen 10 Gigabit Ethernet: 800.000 pakketten per seconde. In praktijk zijn niet alle pakketten de maximale grootte van 1500 bytes, een redelijk gemiddelde is 500. Dus over een volle 10 Gbps-lijn gaan ruim twee miljoen PPS.
Is dat erg?
Eerst wel, nu niet meer, op langere termijn weer wel
Ruim tien jaar geleden, toen de eerste Gigabit Ethernet (GE) Network Interface Cards (NICs) op de markt kwamen, waren PC's hardwarematig noch softwarematig in staat honderdduizend pakketten per seconde af te handelen. Die 1000 Mbps haalde je dus bij lange na niet. Op zich niet erg; de Eerste Wet van Van Beijnum zegt: er is altijd ergens een bottleneck. Als het niet de CPU is dan is het wel het netwerk, en als het niet het netwerk is, dan wel de software, en als het niet de software is, dan wel de bus, en als het niet de bus is, dan wel de CPU... (Nee, verder dan die eerste wet ben ik tot nu toe niet gekomen.)
Jumboframes
Maar diezelfde bedrijven die binnen de IEEE 802.3 werkgroep netjes iedere keer voor het handhaven van 1500 bytes stemden, bouwden ondertussen hardware die veel grotere "jumboframes" aankon, vaak van 9000 bytes. Aangezien de ontvangende computer een flink aantal handelingen per pakket moet doen, ongeacht de grootte van het pakket, betekende het gebruik van jumboframes het verschil tussen 100% CPU-gebruik voor 50% van de maximale bandbreedte versus 50% CPU voor 100% van de bandbreedte.
Dus: iedereen aan de jumboframes, probleem opgelost? Helaas niet. IP-netwerken gaan uit van het principe dat alle systemen die aan hetzelfde subnet (zoals een Ethernet of een Wi-Fi netwerk) gekoppeld zijn dezelfde maximale pakketgrootte hanteren. (Hoewel in de praktijk de meeste dingen wel goed als je hiervan afwijkt.) En er is geen standaard-jumboframe-grootte. Veel systemen hanteren 9000 bytes, maar mijn nieuwe USB 3 - GE adapter houdt het op 4078. En m'n switch laat pakketten tot en met 1982 bytes door, maar gooit pakketten van 1983 bytes of groter weg. Daarnaast is de volgende 30 jaar vast zitten aan 9000 niet veel beter dan de afgelopen 30 jaar vastzitten aan 1500.
We hebben nu al systemen waarmee zendende computers hun pakketgrootte aan kunnen passen aan wat de ontvanger (TCP MSS optie) en het tussenliggende netwerk (path MTU discovery) aankunnen, maar er moet nog wat meer werk gebeuren voor computers en routers op een lokaal netwerk automatisch de maximale pakketgrootte die de hardware ondersteunt kunnen gebruiken zonder kans op storingen. Zelf heb ik hier binnen de IETF een aanzet voor proberen te geven, maar dit moet nog wat beter.
Het werkt toch?
Tien jaar geleden maakte het gebruik van jumboframes op een LAN flink verschil, maar dat verschil is sindsdien aanzienlijk kleiner geworden, zoniet compleet verdwenen. En niet alleen omdat computers sneller geworden zijn terwijl de meesten van ons (nog?) op diezelfde 1000 Mbps zitten als tien jaar geleden, maar vooral omdat de NICs steeds slimmer geworden zijn. Een moderne Ethernet-adapter kan een flinke lading pakketten ontvangen of versturen (en gelijk ook de checksums uitrekenen) voordat de CPU erbij gehaald hoeft te worden. En in veel gevallen kan de CPU een enkel groot IP-pakket aanmaken, waarna de NIC er een stapel pakketten van 1500 bytes van maakt. (Large segment offload of TCP segmentation offload.)
Waarschijnlijk kunnen computers dus ook zonder jumboframes wel uit de voeten met 10 Gigabit Ethernet. Hoewel dat niet betekent dat jumboframes helemaal geen voordelen hebben. Een niet te versmaden bij-effect van grotere pakketten is dat TCP-verbindingen sneller van hun "slow start" fase opschakelen naar de maximale snelheid die het netwerk aankan.
Maar: routers en switches
Routers en switches moeten voor ieder binnenkomend pakket kijken via welke poort het weer naar buiten moet. Dat gaat over het algemeen via een routingtabel of MAC-tabel in de vorm van een CAM (content-addressable memory). Een CAM is een geheugen met een heel klein beetje rekenkracht gekoppeld aan iedere geheugenplaats. Hierdoor kan je een CAM vragen "op welke geheugenplaats staat MAC-adres 00:23:54:6c:33:47?" Iedere geheugenplaats vergelijkt dan z'n inhoud met de zoekterm, en als de inhoud hetzelfde is geeft de betreffende geheugenplaats een seintje. Dit is supersnel, want al die vergelijkingen gebeuren tegelijkertijd naast elkaar. CAMs zijn wel relatief duur gebruiken veel meer stroom dan gewone geheugens.
De hoeveelheid stroom die een CAM gebruikt hangt ook af van z'n snelheid. Een switch met 24 gigabitpoorten moet 2 miljoen pakketten per seconde afhandelen bij pakketten van 1500 bytes. Als de pakketten zes keer zo groot zijn is dat uiteraard maar een zesde, en zou je dus met een minder snelle, energiezuinigere CAM uit kunnen komen.
Denial of Service
Als we dus wat extra logica in IP inbouwen zodat waar mogelijk automatisch de maximale pakketgrootte gebruikt wordt zouden de gemiddelde pakketgrootte misschien op 3000 bytes kunnen krijgen, en dus uit de voeten kunnen met een CAM die 1 miljoen PPS aankan in een 24-poorts GE switch... behalve dat switches niet gebouwd zijn op de huidige maximale pakketgrootte van 1500 bytes (= 2 MPPS) of de gemiddelde pakketgrootte van zo'n 500 bytes (= 6 MPPS) maar op de minimale pakketgrootte van 64 bytes = 36 MPPS...!
Immers, als je een switch (of router) bouwt die 1 MPPS aankan, dan kan je er donder op zeggen dat als iemand een denial-of-service-aanval lanceert, deze meer dan 1 MPPS zal gebruiken, om zo de switch of router op de knieën te krijgen. (Vergelijkbaar met de Slammer worm uit 2003.)
Veel of kleine pakketten, niet veel kleine pakketten
De laatste stap in het efficiënter en groener maken van 't internet door middel van grotere pakketten moet dus bestaan uit het bestrijden van onnodig kleine pakketten. De volgende observatie kan hier uitkomst brengen: er zijn applicaties die veel pakketten genereren (zoals het versturen van grote bestanden). Er zijn ook applicaties die kleine pakketten genereren (zoals Voice over IP). Maar tenzij ik me vergis zijn er geen applicaties die veel kleine pakketten genereren.
Je zou dus op een consumentenverbinding de regel in kunnen voeren dat de gemiddelde pakketgrootte minimaal bijvoorbeeld de helft van de maximale pakketgrootte moet zijn. Op mijn Ziggo-lijn met 6 Mbps upstream zou ik dan 950 pakketten per seconde mogen versturen. Dat is ruim voldoende voor 10 simultane VoIP-gesprekken en zit andere applicaties al helemaal niet in de weg. Natuurlijk liggen de zaken ingewikkelder voor poorten waar een VoIP-provider of een grote DNS-server achter zitten.
Internetters aller landen verenigt u, en werp het juk van de 1500 bytes af!
Permalink - posted 2013-09-25
