'Fujitsu's op udp gebaseerd netwerkprotocol is tot 30 keer zo snel als tcp'

Fujitsu heeft naar eigen zeggen een nieuw en propriëtair transmissieprotocol ontwikkeld op basis van udp dat ten opzichte van tcp tot dertigmaal hogere doorvoersnelheden mogelijk maakt. Ook de latency zou fors verlaagd kunnen worden.

Het nieuwe protocol maakt gebruik van de sterke punten van udp, een netwerkprotocol dat gebruikt wordt voor toepassingen als streaming media en online gaming. Udp weet gemiddeld hogere snelheden te behalen dan tcp, maar het protocol beschikt niet over een mechanisme voor het opnieuw versturen van datapakketjes als deze niet aankomen op de plek van bestemming.

Fujitsu stelt dat zijn nog naamloze protocol de latency van tcp bij het opnieuw versturen van data bij slechte dataverbindingen sterk kan reduceren. Dit zou mogelijk zijn doordat het protocol een eigen controlemechanisme heeft en op hoge snelheid onderscheid zou kunnen maken tussen lost packets en pakketjes die nog niet zijn gearriveerd op de plek van bestemming.

Fujitsu claimt dat tijdens tests met het versturen van bestanden tussen Japan en de VS snelheidswinsten met een factor 30 zijn behaald. Bij het gebruiken van virtuele desktops over dezelfde verbinding zou de latency slechts 1/6 bedragen ten opzichte van eerder gemeten niveaus.

Het protocol zou als software-uitbreiding boven op een udp-stack kunnen draaien. Verder claimt Fujitsu dat een groot aantal internettoepassingen die gebruikmaken van tcp zonder verdere aanpassingen gebruik kan maken van het nieuwe protocol. Het Japanse bedrijf wil zijn netwerkprotocol aan andere bedrijven gaan verkopen in de vorm van middleware.

Reacties (68)

[Dennizz]

Hmm, niet echt nieuws in mijn ogen. Door de control's van TCP te verplaatsen naar een hogere laag kun je inderdaad bepaalde "nadelen" van TCP oplossen, maar er wordt even voorbij gegaan aan het feit dat binnen TCP al veel te tunen valt voor specifieke scenario's. Indien je een high latency verbinding met packetloss hebt, kun je bijvoorbeeld spelen met de window sizing en hoe snel deze opschaalt. De 30x sneller stelling lijkt me gebaseerd op "sane default" van een willekeurig OS. Zeker niet geoptimaliseerd voor de specifieke situatie. Ik zeg niet dat TCp per definitie even snel kan werken als UDP, maar ik denk dat dit meer een slim geschreven marketing middel is voor een commercieel product. Overigens lijkt me in de huidige tijd een implementatie van een proprietary protocol not done.

Daarnaast zijn er al vaker dit soort ideeen uitgewerkt en geoppert. Zoals Reliable UDP bijvoorbeeld. Ook heeft een UDP header bepaalde controls niet in de header, zoals handeling van fragmentatie.

Daarnaast geeft het feit dat TCP, sessie gebaseerd is (i.t.t. connectionless UDP), tussenliggende apparaten als proxies en firewalls veel meer handvaten of iets zinnigs met het verkeer te doen.

Dit protocol zal niet spoedig de wereld gaan veroveren ;-).

[Reactie gewijzigd door Dennizz op 23 juli 2024 17:02]

[Bl@ckbird]

Inderdaad. Technieken als Cisco WAAS en Riverbed Steelhead doen dit al jaren.

Het protocol van Fujitsu doet alleen TCP optimalisatie. (Aangezien het daar een vervanger voor is.)
Het is geen synchrone cache, het doet geen compressie van data en het doet geen deduplicatie van data. En voor echt hoge latency links kan je het Space Communications Protocol gebruiken.

[kdekker]

Dit protocol heeft geen zin voor korte afstanden. Op korte afstanden zijn verbindingen doorgaans betrouwbaar genoeg (tenzij je een brakke kabel hebt of wat anders). En wat Denizz ook al zegt: ergens moet er controle zijn. Een overgefloten bestand wil je graag in exact dezelfde vorm ontvangen. Bij TCP/IP regelt de TCP stack dat, bij UDP mag je dat zelf doen.

Packet los door slechte verbindingen kun je niets aan doen. Het kost hoe dan ook een recovery m.b.v. checksums of resent. En bij erg slechte verbindingen komt er helemaal geen bit goed aan de overkant. Daarmee is genoemde test kennelijk toch wel onder redelijk optimale omstandigheden uitgevoerd.

De latency die je hebt door de grote afstanden, kun je ook niets aan doen (hangt van je voortplantingssnelheid af van je signaal), maar de latency die optreedt door opnieuwe verzenden is wel te verbeteren (met TCP met settings, en Fujitsi heeft zijn eigen mechnaniek uitgevonden). En de keuze van een protocol (mate van overhead) speelt een rol.

Ik zou niet weten in hoeverre de TCP/IP stack van bijv. Windows onderscheid weet te maken tussen long & short distance verbindingen, en on-the-fly TCP/IP settings (bijv Windows size) aanpast. Wellicht is daar ook nog een hoop te winnen?

[pleinolijf]

M.a.w. voor intra-continentale verbindingen zie je geen verbetering, als ik het juist interpreteer ? (Intra-continentaal as in: tussen België en Duitsland bvb.)
Want dan loopt de grafiek gelijk met tcp, wat mij doet aannemen dat in dat geval udp sneller is dan zowel tcp als dit nieuwe protocol. Sterker nog, dan is dit nieuwe protocol zelfs niet sneller dan tcp, wat dan weer opmerkelijk is !

[Reactie gewijzigd door pleinolijf op 23 juli 2024 17:02]

[Mr_Light]

Het protocol gaat beter om met high latency / high package-loss verbindingen. OF eigenlijk beter gezegd TCP gaat er heel slecht mee om. Deze problemen worden uitvergroot wanneer de verbindingen sneller worden. De afgelopen 10 jaar zijn er heel wat papers uitgekomen met oplossingen ik vermoed dat een aantal van deze zijn gecombineerd en geïmplementeerd.

http://fasterdata.es.net/...ing/tcp-issues-explained/ beschrijft een deel van de problemen.

[flabber]

Nee, daar is ook verbetering, maar de grootte daarvan is lager.
Kijjk maar naar de grafieken, het gedeelte "within Japan" laat toch nog steeds verbetering zien.

Daarnaast gaat het niet zozeer over internationaal/intercontinentaal, maar over de 'lengte' van het netwerk en de kans op packetloss. Juist op dat punt zit de verbetering, dus die is het grootst op netwerken met veel packet loss en dat is meestal de meest verre verbinding.

[roy-t]

De grootste winst van dit protocol is wanneer een pakketje verloren raakt, hoe groter de afstand, hoe groter de kans dat dit gebeurt. Op je lokale netwerk zal het dus 0 nut hebben, maar tussen landen misschien al wel een beetje.

[Tamarinde]

Was mooi geweest als ze UDP ook in de vergelijking hadden meegenomen

[flabber]

Dat is in dit geval een beetje zinloos.
Een video streamen via UDP is prima, omdat packetloss niet uitmaakt.
In dit geval wil je wel een vergelijking tussen protocollen die wel een garantie bieden op wat er binnenkomt.
Probeer maar een versleuteld bestand via UDP te verzenden en kijk of je het aan de andere kant nog kan ontsleutelen.

[Amanoo]

Overigens kan dit best, maar dan zal je in de applicatielaag extra overhead moeten toevoegen. Het zal niet efficiënter zijn dan meteen TCP toepassen, maar het kan.

[Jheroun]

Dat lijkt me ook precies wat fujitsu heeft uitgewerkt. Applicatie level controle, daaronder gebruiken ze gewoon UDP.

Dus dit is geen netwerkprotocol maar een applicatieprotocol, het netwerkprotocol is gewoon UDP.

Zoals al eerder gezegd komen er wel meer van dit soort dingen langs, vaak ontwikkeld door partijen die een applicatie bieden die zowel lage latency als betrrouwbaarheid vereisen. Daarmee zal het dus concurreren, niet met TCP of UDP.

[280562]

Als je heel precies wilt zijn, dan is het ook geen applicatie protocol. Een applicatie protocol is een protocol dat binnen in de applicatie wordt geprogrammeerd. Dat is dit niet. (HTTP is een soort applicatie protocol). Dit nieuwe protocol wordt (kant-en-klaar) gebruikt door de applicatie. Het is een soort "middle-ware". Tussen de applicatie en het OS in.

IP is een netwerk protocol. Ik durf zelfs te stellen: IP is het netwerk protocol.
UDP zit daar een laag boven. UDP is een transport protocol. (Net als TCP).
Dit nieuwe protocol zit daar weer boven.

De best naam, imho, zou zijn: dit is een soort session-protocol.

(Netjes volgens het OSI model. Maar zelfs dan voldoet het waarschijnlijk niet aan de voorwaarden die het OSI model stelt aan een session-protocol. Bv omdat we in de IP wereld geen echte EndPoint-Indentifiers hebben (alleen interface-addressen)).

[Reactie gewijzigd door 280562 op 22 juli 2024 15:39]

[Ongepast]

Zat ik dus ook te denken. Dit is een beetje dat je een auto, die op een ferrari is gebaseerd ga vergelijken met een lada.

[roy-t]

Nee want dan vergelijk je een protocol dat niets doet met verloren pakketten met een protocol dat er voor zorgt dat alles altijd aankomt. Appels en peren dus.

[Durandal]

Ik zie het grote voordeel nog niet erg, maar misschien heeft iemand wat meer inzicht.
Ik zie een de volgende meestgebruikte scenario's
- je wilt gamen o.i.d. : hier heb je dan een lage latency nodig met bij voorkeur weinig packet loss. De packet loss kan je niet verhelpen. Over het algemeen gaat je game client gewoon door als er packet loss is en corrigeert met de informatie uit de volgende packets die wel aankomen. Er worden dus geen packets herzonden, dus heeft dat protocol hier niet veel nut.
- je wilt video streamen : Hier maakt de latency niet uit. Tuurlijk, het is vervelend als je het doelpunt bij de buren een seconde eerder hoort maar hele volksstammen leven daar al mee. Wat packet loss maakt over het algemeen ook niet veel uit in een video stream. Overigens worden video streams gebufferd.
- je wilt (grote) files transferren: Dit gebeurt met TCP omdat je geen last van lost packets wilt hebben. Latency maakt niet uit en op een grote file maakt een seconde langer ook niet uit.

Fujitsu heeft een protocol gemaakt dat zo snel en low-latency is als UDP en zeker als TCP (claimen ze, in simulaties). Ik zie alleen de use-case niet. Je hebt genoeg aan de huidige keuze.
Mis ik iets?

Verder blijft Engels moeilijk voor Japanners (latancy)

[Reactie gewijzigd door Durandal op 23 juli 2024 17:02]

[TheekAzzaBreek]

Dit protocol vangt wel packet loss op, het doet het alleen efficiënter. En kennelijk doet het ook aan slimme QOS:

1) A new protocol that incorporates an efficient proprietarily developed retransmission method based on user datagram protocol (UDP)(2), an optimized way to deliver streaming media able to reduce latency resulting from data retransmission when packet loss occurs; 2) Control technology that addresses the problem of UDP transmissions consuming excess bandwidth by performing a real-time measurement of available network bandwidth and securing an optimal amount of communications bandwidth without overwhelming TCP's share of the bandwidth; and 3) Technology that, by employing the new protocol, makes it possible to easily speed up existing TCP applications without having to modify them.

(bron)

[Jheroun]

Waarbij je je meteen af kan vragen waarom je dan niet gewoon binnen de parameters van TCP een en ander zou gaan tweaken. En als er dan nog dingen beter moeten kan je als je wilt nog naar QoS kijken, hoewel de meest effectieve oplossing daarbij nog steeds is: meer bandbreedte ertegenaan gooien.

Dit verhaal levert een leuk stukje octrooi op voor Fujitsu, een leuke bonus voor de medewerkers die het verzonnen hebben en wellicht een paar rechtzaken als ze gaan vinden dat iemand straks inbreuk pleegt op hun idee.

En verder draait het Internet gewoon verder op UDP en TCP.

[hawkeye73]

Viel me ook al op ja... dacht wat is dat nu weer (latancy ipv latency)

1x fout en 1x goed...

[Reactie gewijzigd door hawkeye73 op 23 juli 2024 17:02]

[twiFight]

Je denkt als een thuisgebruiker. Fujitsu maakt geen producten voor Henk en zijn gezinnetje thuis! Gamen en video streamen zal daarom niet bij de doelsystemen horen voor Fujitsu.

Waar je aan moet denken zijn productiesystemen, databases etc. die real-time werken en afhankelijk zijn van een snelle en 100% complete overdracht van gegevens. Vertraging in de systemen kan productie vertragen en dat loopt bij bedrijven al snel op tot grote bedragen. Een seconde is geen ramp maar een seconde vertraging per transactie kost bedrijven enorm veel geld.

[Jheroun]

Dat zijn typisch transacties op korte afstanden in betrouwbare omgevingen met dikke links. Daar is dit protocol dus niet op van toepassing aangezien ze het in de test juist hebben over een langeafstandsverbinding over brakke links (gezien de hoeveelheid latency die ze zonder dit wonderprotocol hadden).

[TheekAzzaBreek]

Dat is niet meer zo. Veel bedrijven (de meesten zelfs die ik van binnen heb gezien) hebben hun datacenters outsourced. En zelfs al hebben ze hun eigen centers, dan hebben ze doorgaans nog een uitwijkcenter op behoorlijke afstand. Internationale bedrijven centraliseren naar enkele datacenters voor een groot aantal landen. Als dit het mogelijk maakt met minder datacenters te werken zou het veel geld besparen.

[Jheroun]

Dan nog ligt er tussen die datacentres echt een pad dat zo goed is dat je je kan afvragen of dit soort technologie kan helpen. Ze hebben het in het voorbeeld over een pad met drie hele seconden delay, dat is erg veel. Bovendien is bij een DC voor uitwijk de betrouwbaarheid stukker belangrijker dan de latency, dan ga je niet zitten prutsen met een of andere optimalisatie in je applicatielaag.

[Anoniem: 270261]

zeker niet slecht zolang ze werkelijk packetloss kunnen opvangen en niet gewoon als udp doorgaan zonder de "lost packets"

_{Fujitsu claimt dat tijdens tests met het versturen van bestanden tussen Japan en de VS snelheidswinsten met een factor 30 zijn behaald. Bij het gebruiken van virtuele desktops over dezelfde verbinding zou de latency slechts 1/6 bedragen ten opzichte van eerder gemeten niveaus}

zal zeker een vooruitgang zijn in de gamewereld voor fps games of zelfs platform games met minder latency.. spelen op amerikaanse servers gaat dan toch eindelijk mogelijk zijn zonder 300 ping te hebben

[Reactie gewijzigd door Anoniem: 270261 op 23 juli 2024 17:02]

[roy-t]

Games gebruiken vaak al UDP voor het snelle verkeer (beter dat je een 'stapje mist' van een speler dan dat iedereen moet wachten totdat iedereen elkaars stapje heeft). Alleen voor belangrijkere data waar latency minder belangrijk is (zoals chat of punten) wordt TCP gebruikt.

[Anoniem: 270261]

inderdaad ook veel gewoon een mix van de 2 maar een soort tcp protocol maar dan veel sneller zou zeer handig zijn ook vanwege een verloren paketje dat een "kogel" bevat wat een headshot zou moeten voorstellen... mis je ff je headshot momenteel via udp, via het nieuwe protocol zou dit niet het geval zijn, bij tcp ook niet maar tcp is veel te traag voor gaming zeker voor fps

in een echte omgeving weet ik niet of dit daadwerkelijk zo is maar denk dat men punt hier wel duidelijk is

[Jheroun]

Die headshots missen dan niet, dit zijn die situaties waarin je niks zag gebeuren maar wel ineens dood neervalt

De gamemechanics houden echt wel betrouwbaar bij wat er allemaal rondvliegt, er wordt alleen geen moeite gedaan om de visuele updates betrouwbaar te maken aangezien latency belangrijker is dan een dropped frame ofzo (ik weet de exacte mechanics niet).

En bovendien, hoe vaak maak je tegenwoordig packetloss mee als je op een server binnen west europa speelt?

[3dfx]

En bovendien, hoe vaak maak je tegenwoordig packetloss mee als je op een server binnen west europa speelt?

Iedere dag als je een Telfort-klant bent...

[Dekker3D]

Om precies te zijn gebruiken veel games "reliable UDP". Het simuleert TCP's zekerheid op belangrijke packets (schoten enzo), maar gebruikt gewone packets voor dingen als lopen enzo.

[Gettow]

Zo zijn er wel meer protocollen die UDP gebruiken, bijvoorbeeld FASP van Asperasoft: http://asperasoft.com/technology/transport/fasp/

[Amanoo]

Dit protocol is naar mijn begrijpen geen een die gebruik maakt van UDP, maar een alternatief voor UDP (en TCP).

[.oisyn]

Het is een alternatief voor TCP dat geïmplementeerd is middels UDP.

[Moraanl]

UDP is ook gebruikt bij gaming?

[Jheroun]

Ik kan niet precies aflezen of je statement wel of niet als vraag bedoeld is, maar ja. Bij gaming is het (afhankelijk van de game) van belang dat je pakketjes snel binnenkrijgt. Als er een pakketje mist is hertransmissie weinig zinnig, je bent dan immers al weer verderop in de game dus een geretransmit stukje informatie over, bijvoorbeeld, de locatie van andere spelers heeft geen zin meer, als dat aankomt is die locatie alweer ververst door nieuwere informatie.

Hangt wel sterk van de game af natuurlijk, een shooter is hier gevoeliger voor dan een MMORPG ofzo.

[mindcrimemike]

Vooral erg fijn als je een dedicated verbinding hebt waarvan je de utilisatie zo hoog mogelijk wilt krijgen. Nu plemp je een lijn vol met meerdere TCP verbindingen zodat de som van feitenlijk verstuurde data ook zo hoog mogelijk tegen de maximale lijn utilisatie zit.
Als de preciese volgorder van aankomst van de data niet essentieel is kan je dan niet net zo goed meerdere TCP sessies opstarten zoals een FTP download manager dat voor je regelt? Toch?
Wat snap ik niet?

[Jheroun]

Als je meerdere logische verbindingen op je fysieke link nodig hebt om hem uit te nutten moet je vooral aan het engineeren in de manier waarop de applicatielaag met de data omgaat, die zit dan kennelijk te vertragen (overigens inderdaad een probleem met veel protocollen).

Dit gaat vooral over latency, de responssnelheid na het versturen van een pakketje en het ontvangen van het antwoord daarop. Waar jij het over hebt is de te benutten bandbreedte. Die staat daar min of meer los van. Wat zij hier doen is analoog aan een snellere motor in een auto zetten zodat hij eerder op de plaats van bestemming is. Waar jij het over hebt is de uitbreiding van de kofferbak

Het effect van korte latency is (ook binnen TCP overigens) dat de eindstations eerder door hebben wat de maximale snelheid is waarmee ze kunnen communiceren, daarom ontstaat in dit verhaal het verband tussen bandbreedte en delay.

[Reactie gewijzigd door Jheroun op 23 juli 2024 17:02]

[Bl@ckbird]

Waar jij het over hebt is de te benutten bandbreedte. Die staat daar min of meer los van.

Nee. TCP moet packets acknowledgen of ze zijn aangekomen. Je download een bestand over de satelliet link.

• 10 IP packets worden gedownload.
• 500ms wachten
• TCP upload een acknowledgement
• 500ms wachten
• 10 IP packets worden gedownload.
• 500ms wachten
• enz.

Dit wordt erger als je packetloss hebt. Stel je hebt een 1Gbps satelliet link met 500 ms latency. Hier staat een calculator. Bij een gigabit link met 500ms latency hou je per TCP flow slechts 1.04Mbps over. Voeg je 1% packetloss toe, dan blijft hier nog maar 0.23 Mbps van over. Bij een gigabit link met 500ms latency moet je downloadmanager dus 1000 sessies opzetten (van 1Mbps elk) om de lijn dicht te kunnen trekken.

[Reactie gewijzigd door Bl@ckbird op 23 juli 2024 17:02]

[johnkeates]

Nee, zo werkt het niet. Het is niet zo dat 1 TCP verbinding een limiet heeft, maar dat op een slechte verbinding veel retransmissies plaatsvinden, en dat dat dus tijd kost, en ook bandbreedte.

Dit 'geheime' protocol heeft dat op een andere manier voor specifiek dit soort problemen anders opgelost, waardoor er meer informatie heen en weer kan.

[jerrevds]

In mijn ogen is het een beetje zinloos een UDP alternatief (waar packetloss mogelijk is) te gaanvergelijken met TCP dat juist zekerheden aanbieden.

Het is een beetje appels met peren vergelijken wat ze hier doen aangezien zonder retransmissie UDP per definitie beter doet dan TCP en ik van een "opvolger" van UDP dan ook soortgelijk resultaat zou verwachten, vooral als deze geen extra veiligheidslagen inbouwt...

(wat niet wegneemt dat dit protocol beter kan zijn dan standaard UDP en een mooie winst oplevert natuurlijk, maar ze beiden niet echt vegelijkingsmateriaal...).

[MadEgg]

Dit zou mogelijk zijn doordat het protocol een eigen controlemechanisme heeft en op hoge snelheid onderscheid zou kunnen maken tussen lost packets en pakketjes die nog niet zijn gearriveerd op de plek van bestemming.

De vergelijking is wel degelijk terecht. Ze hebben een protocol ontwikkeld dat met behulp van UDP (wat inderdaad packet loss negeert) vergelijkbare kwaliteiten als TCP oplevert: het detecteert welke pakketjes verloren gegaan zijn en zal die opnieuw versturen. Je kunt er dus zeker van zijn dat álle data bij de ontvanger aankomt, in tegenstelling tot standaard UDP. Het is dus in zekere zin een concurrent voor TCP.

Wat ik zelf echter niet snap is waarom ze dit bovenop UDP gedaan hebben. Het idee achter UDP is inderdaad dat het niet boeit dat wat pakketjes verloren gaan, terwijl bij TCP die garantie er wel is. Als Fujitsu een protocol wil ontwikkelen dat beter presteert dan TCP maar wel gelijke kwaliteiten hebben snap ik niet dat ze dit niet ook als transport layer protocol hebben gedaan maar als application layer protocol (bovenop UDP dus): hoe efficient ook, het stapelen van protocollen levert altijd enige vorm van overhead op.

[SnowDude]

Doordat dit op standaard UDP draait kan dit gewoon worden gerouteerd zonder alle routers aan te passen. Als ze een compleet nieuwe protocol op OSI laag 3 hadden ontworpen dan moeten ook alle gebruikte routers worden geupdate.