Nieuw machinelearning-programma handelt opstopping netwerk efficiënter af

Ontwikkelaars van het MIT hebben een computerprogramma ontwikkeld dat automatisch algoritmes voor tcp genereert om opstoppingen in netwerken tegen te gaan. Bij simulaties kon hiermee de doorvoersnelheid van een netwerk verdubbeld worden ten opzichte van andere tcp-versies.

Tcp is geoptimaliseerd voor accurate levering van bestanden en het tegengaan van netwerkcongestie is dan ook een belangrijk onderdeel van het protocol. In het verleden zijn veel verbeteringen en wijzigingen aangebracht aan het tcp congestion avoidance algorithm, wat heeft geleid tot varianten als TCP Cubic die standaard in Linux-kernels verwerkt zit en Compound TCP van Microsoft. Ontwikkelaars van het MIT hebben nu een softwareprogramma met de naam Remy ontwikkeld die met automatisch gegenereerde algoritmes congestie veel beter afhandelt dan de door mensenhanden gemaakte algoritmes.

Voor de werking van Remy geven gebruikers eigenschappen van het netwerk aan, zoals gegevens met betrekking tot de bandbreedte, gebruikers en gebruik van het netwerk. Ook kunnen ze de mate van prioriteit op gebied van doorvoer en delay aangeven. Remy test vervolgens een hele reeks aan algoritmes bij verschillende scenario's en onderzoekt verdere variaties die de beste uitkomsten geven. Voor snelle werking spendeert Remy weinig tijd aan voorspelbare uitkomsten en richt de software zich op analyse van gevallen waarbij kleine variaties van de netwerkconditie voor grote verschillen in prestaties zorgen.

In plaats van de handvol regels die de huidige tcp-varianten bieden als reactie op potentieel netwerkvertragende gebeurtenissen, kan Remy er meer dan 150 produceren. "Tcp heeft traditiegetrouw relatief eenvoudige eindpuntregels maar complex gedrag als je die daadwerkelijk toepast", zegt Keith Winstein van het ontwikkelteam, "Met Remy is dat precies andersom. We denken dat dit beter is omdat computers goed kunnen omgaan met complexiteit: je wil dat het gedrag simpel blijft."

Bij simulaties van een snel bedraad netwerk wist Remy de delay met tweederde terug te brengen en de doorvoersnelheid grofweg te verdubbelen ten opzichte van Compound TCP en TCP Cubic. De onderzoekers simuleerden ook een complex netwerk zoals die van Verizons mobiele netwerk: daar bedroeg de verbetering van het terugbrengen van vertraging 25 tot 40 procent, terwijl de doorvoersnelheid 20 tot 30 procent hoger lag.

Reacties (26)

[wootah]

In het grafiekje zie je een paar TCP queueing protocollen staan.
Standaard staat in linux het queueing protocol op TCP cubic als ik mij niet vergis. Dat is gewoon een all around algoritme voor opstoppingen op te lossen.

Ik heb mijn router toevallig op TCP Vegas ingesteld omdat ik altijd graag een lage delay wil hebben.
in linux kun je dat zo aanpassen of uitlezen wat jouw OS gebruikt:

cat /proc/sys/net/ipv4/tcp_congestion_control

(je moet wel de modules er voor hebben geladen als je hem wil aanpassen)

Gaan deze algoritmes echt de wereld veranderen? Mwa, vooral bij hoge netwerk belasting zou je er iets van kunnen merken. Als de maximum snelheid van de netwerk interfaces bereikt worden dan zal dit algoritme wel iets van verschil kunnen laten zien.
Dit algoritme houd geen rekening met UDP verkeer, dus daar zal het geen problemen oplossen.

Persoonlijk denk ik dus nog steeds dat men gebruik moet maken van QoS technieken om echt een goede balans te vinden in netwerk doorvoer snelheid en delay. Voor de gemiddelde computer gebruiker zal dat ook het effectiefst zijn.

[fevenhuis]

Met het oog op DDoS aanvallen lijkt mij dit een uitstekende ontwikkeling.

[Mr_gadget]

Denk niet dat dit heel veel gaat oplossen bij DDoS aanvallen. Bij een DDoS aanval is de routering meestal niet de bottleneck. Het gaat vaak fout op de ontvangende server die overbelast raakt of de directe verbinding naar de server loopt vol. Daar gaat dit niet heel veel aan oplossen.

[SirBlade]

Maar misschien kan dit gebruikt worden om een DDOS te detecteren en die packets dan te droppen voordat ze bij een server komen.

[fevenhuis]

Ongeacht hoe een DDoS aanval werkt, is het resultaat dat het netwerk overbelast wordt, als netwerk dus efficiënter werkt zal het moeilijker zijn om het netwerk plat te krijgen, dus ook met een DDoS aanval.

En ik vermoed dat moderne netwerk (DDoS) aanvallen zowel op routering als wel op server bediening gericht zijn.

Ook denk ik dat routers toch wel degelijk het eerste struikelblok van DDoS aanvallen zijn, maar wellicht pakt dat toch wat anders uit bij grotere netwerken.

[Mr_Light]

Even de link in het artiekel volgen..
https://github.com/keithw/remy

We believe that making congestion control a function of the desired ends, and the assumptions we make about the network, is the
solution to allow the Internet and its subnetworks to evolve without
tiptoeing around TCP’s assumptions about how networks behave.
But many dots need to be connected before the the Internet at large
— as opposed to internal networks — might agree on a model that
could be used to prepare a “one-size-fits-all” RemyCC.

Dus als je bijvoorbeeld een NREN hebt kan je er al mee stoeien

Het is een programma welke decentrale algoritmes genereerd die bepalen hoe met situaties om moet worden gegaan. (Parameters instellen op basis van vastgesteld gedrag van het netwerk(dmv geobserveerde metrieken, package loss, latency etc)

//edit specifiek:

Remy is run as an offline optimization tool to create a new congestion-control scheme. As input, it takes:

the protocol designer's prior knowledge or assumptions about the network. Is the wire speed known in advance, or is it subject to uncertainty? (Some protocols, such as XCP or pFabric, want to know the wire speed exactly.) What are the range of round-trip times the protocol may encounter? These assumptions are encoded into a network model.
a traffic model expressing the needs of the users on the network, as a stochastic model expressing when flows start and stop.
an objective function for what the protocol should aim to maximize. The sum of the log of each user's throughput? Throughput divided by delay ? Flow completion time?

(RemyCC) tracks three state variables:
a moving average of the inter-arrival time of acknowledgments from the receiver
a moving average of the sender's outgoing timestamp echoed in those acknowledgments
the ratio between the most recent round-trip-time measurement and the minimum observed so far on this connection

The RemyCC maps regions of this state space to an action:

a multiplier to the current congestion window
an increment to the congestion window
a minimum interval between outgoing packets (for pacing)

[Reactie gewijzigd door Mr_Light op 24 juli 2024 04:17]

[Odyssey]

Zoals ik het in het artikel lees is het eerder een protocol en zou dat dus bij de linux kernel zelf meegebracht worden (MIT kennende). Maar misschien begrijp ik het verkeerd.

[Amanoo]

Naar ik begrijp is dit niet direct een protocol. Het is volgens mij een uitbreiding/software die op netwerk nodes draait en die het TCP protocol helpt om efficiënter te worden.

[hardwareaddict]

Het principe van meerdere heuristieken gebruiken om iets voor elkaar te krijgen is natuurlijk geen slecht idee.

Echter in dit geval is het een studie die direct de ladekast inkan en verstoffen gaat. Tegenwoordig wordt elke onderzoekje wel gepost op tweakers in dat opzicht.

Even een paar citaten: "We have implemented Remy. Running on a 48-core server at MIT, Remy generally takes a few hours of wall-clock time (one or two CPU weeks) to generate congestion-control algorithms offline that work ona wide range of network conditions."

Kijk, dat soort onderzoeken kennen we heel goed.

Als jij een specifieke workload eerst helemaal doodanalyseert statistisch, dan krijgt iedereen met wat algoritmische kennis het voor elkaar om dat efficienter te verwerken.

Probleem is dat het dan alleen werkt voor dat specifieke voorbeeld van je en niet in 't algemene geval. En ook: HEB JE ER WEL DE SYSTEEMTIJD VOOR om elke paar pakketjes die je versturen gaat helemaal dood te analyseren eerst gedurende een aantal uur rekentijd?

In die tijd kun je namelijk heel wat verzenden...

Wat verder ook ontbreekt is een keihard wiskundig bewijs dat hetgeen hun orakel produceert aan heuristieke, dat deze ook bugvrij gaat werken en met name niet een of andere worst case introduceert die niet om aan te zien is.

uit 6. Discussion: "Much remains unknown about the capabilities and limits of computer-generated algorithms, ...."

Dus de ladekast.

Ik ken iets wat nog beter werkt dan dit. Dat is eerst een supercompressor gebruiken om elk pakketje te compresseren en dan pas te verzenden. Je haalt dan heel wat meer dan factor 2 speedup

Natuurlijk werkt de hardwarematige compressie iets minder in zo'n geval.

Als het gaat om heuristieken en parametertuning dan blijft nog steeds hetzelfde lemma van kracht: "iets wat goed werkt is topsecret en hoor je nooit wat over".

Uit de discussion: "..., we can't be certain how well RemyCC's will perform on real networks without trying them."

Zelfs pkzip jaren 90 werkt beter dan dit.

Het onderzoekje van 20 in het dozijn te snel gepost op tweakers dus.

[Reactie gewijzigd door hardwareaddict op 24 juli 2024 04:17]

[Mr_Light]

Ik snap niet dat je omhoog gemod bent want er klopt niet veel van wat je zegt...

Probleem is dat het dan alleen werkt voor dat specifieke voorbeeld van je en niet in 't algemene geval. En ook: HEB JE ER WEL DE SYSTEEMTIJD VOOR om elke paar pakketjes die je versturen gaat helemaal dood te analyseren eerst gedurende een aantal uur rekentijd?

1. je berekend het niet per paar pakketjes, zelfs niet per end node/installatie maar per type netwerk en dan kan je het resultaat gewoon naar miljoenen computers uitrollen.

2. Als je de build time van veel gebruikte software pakketten er bij pakt dan zie dat die minstens net zo lang duren. En het stuk software dat TCP congestion control doet wordt veel vaker uitgevoerd.

3. In de gevallen waarin de aannames fout zijn is ook gewoon doorgerekend en getest en het gegenereerde algoritme blijft beter voor situaties waar de aanname factor 10 er naast zit(zie paper)

In die tijd kun je namelijk heel wat verzenden...

zie bovenstaand.

Wat verder ook ontbreekt is een keihard wiskundig bewijs dat hetgeen hun orakel produceert aan heuristieke, dat deze ook bugvrij gaat werken en met name niet een of andere worst case introduceert die niet om aan te zien is.

Ja en de enige manier om dat te bewijzen is het hele internet er op te laten draaien, alle aanpassingen die zijn geweest en nog komen hebben dit nooit van te voren bewezen....

Uit de discussion: "..., we can't be certain how well RemyCC's will perform on real networks without trying them."

zie hierboven.

En voor de ruis er tussen in zou ik maar gewoon een aluminium hoedje opzetten.

Het belangrijkste resultaat waar je totaal aan voorbij gaat is dat het gegenereerde resultaat niet overtroffen wordt mensen en dus net zo als bij schaken en jeopardy! de mens buitenspel is gezet.

[MSalters]

Lol, "belangrijk om TCP pakketjes niet kwijt te raken". De hele reden voor TCP over IP is nu juist dat je pakketjes kwijtraakt, en dat gebruikt voor link control

[Dreeke fixed]

Met jou redenatie kan je alles wat ingewikkeld is wel naar de prullebak verwijzen.
Soms heb je voor ingewikkelde problemen een ingewikkelde oplossing nodig.

Alle ontwikkelingen waardoor het tcp protocol in potentie beter wordt is goed.
Misschien dat dir protocol het niet haalt, maar dan zal er zeker nog een worden verzonnen, er zijn er tenslotte pas 6.

[mrfreeze12345]

Interessante technologie. Ik vraag me met dit soort ontwikkelingen altijd wel af, wanneer komt het punt dat er wereldwijd nog slechts een stuk of 6 mensen rondlopen die snappen welk pakketje op welke manier waar naartoe gaat.

[pbruins84]

Dit gaat niet over routering, maar over de snelheid waarmee pakketten worden verstuurd.

[mjl]

Dat doen ze niet per pakket... alleen als er problemen gedetecteerd worden bij een kleine verandering van de data stroom.

Het voornaamste wat ze doen is dus een sensitivity analysis waarbij ze de meest robuste en snele methodes behouden en de disruptieve methodes uit de weg gaan. Als ik het zo begrijp is dat dus afhankelijk van het gebruik van het netwerk en hoe de infrastructuur is opgezet.

[Mr_Light]

De heuristieken bepalen ze ook niet wanneer er een verandering is in de data stroom. Alle oplossingen zijn van te voren al doorberekend - er word een algoritme gegenereerd. Voor de variabelen worden er 8 varianten doorberekend. Als ik het goed begrijp zijn er 3 dus 8x8x8 512 optima, deze worden op basis van een moving avg. van parameters geselecteerd. De berekendtijd van filteren(berekenen moving avg.) is insignificant met de processorkracht van vandaag.

Remy is run as an offline optimization tool

[Reactie gewijzigd door Mr_Light op 24 juli 2024 04:17]

[hardwareaddict]

Je kunt een oplossing van hoe iets te concateneren pas goed doorrekenen als je tevoren de dataload weet.

Op een realtime netwerk weet je niet welke pakketjes je naar welk station versturen moet. Dat weet je pas als je het pakketje krijgt.

Als we dus een parameter optimalisatie doen, zeg gewoon simpele artihmetic routing table, waarin we al tevoren weten hoeveel naar core A gaat en hoeveel naar core B, dan is dat dus heel simpeltjes om goed te doen.

rond de 40% winst claimen is dan echt PEANUTS en behoorlijk prutswerk. Hun winst zit met name in de concatenatie van packets en niet zozeer efficientere vormen routering/compressie.

Zelfs de hardwarematige compressie van de pakketjes compresseert het al minimaal factor 2 als worstcase in realtime environments en dat is een stuk beter dan de hier geclaimde 40%+

Die hardware matige compressie bestaat overigens al heel lang en is dus echt kinderlijk simpel. Dat is net zo iets als het op de beurs verliezen van een gorilla die elk jaar een paar pijltjes gooit op welke aandelen hij inslaat.

Als je daarvan verliest mag je als belegger ook ontslagen worden natuurlijk.

[mrfreeze12345]

Ik heb het toch ook nergens over routering? Dit sóórt ontwikkelingen ...

[Vaevictis_]

Weet iemand of ze dit algoritme als Open Source (MIT License) vrijgeven? Dan kan de rest van de wereld hiermee gaan experimenteren.

Om het echt productierijp te maken zijn we dan nog wel een paar jaar verder. Dus hoe eerder er mee getest kan worden hoe beter.

[T020]

Ja: https://github.com/keithw/remy

Het lijkt me dat hier nog veel vervolgonderzoek op komt. TCP is een van de meest gebruikte protocollen wereldwijd, en deze ontwikkeling kan in de komende jaren veel betekenen voor de snelheid van netwerken in het algemeen :-).

Ik ben ook wel benieuwd naar de resultaten in een echt netwerk, de getoonde resultaten komen allemaal nog uit simulaties.