Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 68 reacties, 15.358 views •

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 netwerkprotocol

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)

Ik kan wel lezen maar ik zeg juist "
dan in de realiteit
".
Ik begrijp dat het hun wens is maar hoe vaak zal dit in de praktijk gebeuren waarbij je op grote schaal dit als consumenten in producten verwerkt gaat zien worden.
op zich zou een licentiemodel toch wel acceptabel zijn?
en een 30x snelheids toename is wel erg veel, nou is dat wss natuurlijk het meest gunstige geval, maar het blijft een enorme winst.

ben benieuwd wat hier verder mee gaat gebeuren. ook interessant voor mogelijk 3g/4g internet of zie ik dat fout, lagere latency en snellere errorcorrectie is daar vooral erg nuttig lijkt me, (op elk draadloos netwerk eigenlijk)
op zich zou een licentiemodel toch wel acceptabel zijn?
Als dit een niche-oplossing blijft wel, maar als ze het grootschalig geaccepteerd willen zien als een nieuwe standaard dan moet het een open standaard zijn, zonder licentiekosten en zonder kosten voor patenten van derden.

Het transport-level protocol voor het internet is domweg te belangrijk voor de rest van de wereld om iets anders te accepteren. (bijv: Cisco wil Fujitsu niet tot in de lengte van dagen betalen, Open source systemen kunnen het dan niet implementeren, etc)
De rest van de wereld zal er dan waarschijnlijk voor kiezen om gezamenlijk een concurrerend protocol te ontwikkelen dat hetzelfde doet.
UDP doet daar dus niet aan het stuurt data over een verbinding en of er nu wel of niet geluisterd wordt maakt niet uit. Ik gebruik het veel in industriŽle omgevingen , voor data die niet heel erg belangrijk is omdat het minder storings gevoelig is.
voor uren tellers en counters die gelogd moeten worden ...

tja je zou het misschien wel kunnen in bouwen aan de ontvangende kant
dat de computer zelf bij houd welke pakketjes aan komen en als er iets mist zou de aan de zendende computer kunnen vragen het nogmaals te versturen
dat genererend natuurlijk veel minder data..
voorbeeld tcp/ip
Ik heb een pak met 100 rietjes en jij wil het pak met rietjes hebben
we onderhandelen en ik stuur 1 rietje per keer naar je op via de post jij stuurt mij een brief terug van ontvangen stuur de volgende maar op. dit gaan we net zo lang doen tot jij alle rietjes hebt... best wel een tijds verspilling niet?

UDP
Idem maar nu stuur de in 1 keer de doos met de 100 rietjes op. Ik heb er geen track en trace op gedaan dus we zien wel of het aan komt.

Het zou fijn zijn als de nieuwe standaard dus zegt van
ik heb de doos binnen gekregen maar ik mis 2 rietjes stuur mij die even na.
dat scheelt heel veel data of we zouden standaard correctie bits moeten versturen en als we dus met films doen (par2 files is een voorbeeld)

[Reactie gewijzigd door Red_inc op 30 januari 2013 19:26]

Idee:
Je kan ook met errorcorrectie (ala DVD) de data opzich zodanig redundant maken dat je de missende paketjes can reconstrueren.
Dan hoef je helemaal niets meer te hersturen en is het alleen problematisch als er zoveel niet aankomt dat het reconstrueren ook niet meer lukt.
En dan ben je inderdaad van die hele handshake af.

[Reactie gewijzigd door trogdor op 30 januari 2013 23:11]

Dat werkt niet als je maar weinig data (een pakketje) te versturen hebt.
tja je zou het misschien wel kunnen in bouwen aan de ontvangende kant
dat de computer zelf bij houd welke pakketjes aan komen en als er iets mist zou de aan de zendende computer kunnen vragen het nogmaals te versturen
dat genererend natuurlijk veel minder data..
Hoezo minder data ?
Wat je daar beschrijft, is wat TCP doet. De overhead van TCP is 20 bytes per segment. (En een segment kan (praktisch) zo'n 1400 bytes lang zijn. Dat is ongeveer 1% overhead (in packetsize). Ga je dat beter doen met je eigen protocol ?
voorbeeld tcp/ip
Ik heb een pak met 100 rietjes en jij wil het pak met rietjes hebben
we onderhandelen en ik stuur 1 rietje per keer naar je op via de post jij stuurt mij een brief terug van ontvangen stuur de volgende maar op. dit gaan we net zo lang doen tot jij alle rietjes hebt... best wel een tijds verspilling niet?
Gelukkig hebben we een "sliding window" in TCP. Van 64k (of groter, met nieuwere, gestandariseerde extensies). TCP zend dus een hoop rietjes achter elkaar, voordat het wacht op een ack.
Het zou fijn zijn als de nieuwe standaard dus zegt van
ik heb de doos binnen gekregen maar ik mis 2 rietjes stuur mij die even na.
dat scheelt heel veel data of we zouden standaard correctie bits moeten versturen en als we dus met films doen (par2 files is een voorbeeld)
Dat bestaat al. In TCP. En heet "selective ack (SACK)".
RFC 2018 uit 1996: http://www.hjp.at/doc/rfc/rfc2018.txt
RFC 2883 uit 2000: http://tools.ietf.org/html/rfc2883

Mensen hebben altijd kritiek op TCP. Dat het traag zou zijn. Dat het veel overhead heeft. Maar als ze dan zelf beginnen met een eigen transport protocol te ontwikkelen, dan blijkt na een tijdje dat ze alle features uit TCP hebben nagebouwd. En dus net zo veel "overhead" hebben.

Alleen als je voor specifieke applicaties een nieuw transport protocol wilt bouwen, dan heb je kans van slagen. Als je een general purpose reliable transport protocol wilt maken, voor zowel grote files als korte transacties, of interactief werk, dan is TCP een uitstekende keuze.

Dit protocol van Fijutsu heeft zich toegelegd op situaties waar je veel packet drops hebt. Tegenwoordig is dat vrij zeldzaam, behalve bij drukke WiFi netwerken. En zelfs dan hangt het er nog maar vanaf. Een maand of wat geleden was er hier een soortgelijk artikel over een ander protocol voor WiFi (met drops). Daar bleek dat de onderzoekers hun protocol hadden vergeleken met TCP zonder SACK. Tsja, dan lijkt het allicht beter dan de TCP van voor 1996.
De doelstelling van Fujitsu zal zijn om er geld mee te verdienen, ze begrijpen zelf ook wel dat ze hiermee niet het internet gaan veroveren.
Het kan bovenop de huidige protocollen verwerkt worden, het is dus gewoon optioneel.

tcp en upd liggen zo vast idem moet alle router dat ze sowieso moeilijk vervangen kunnen worden. Maar we zullen zien of de markt dit wil betalen.
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 30 januari 2013 13:38]

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.
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.
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.
Zo zijn er wel meer protocollen die UDP gebruiken, bijvoorbeeld FASP van Asperasoft: http://asperasoft.com/technology/transport/fasp/
Dit protocol is naar mijn begrijpen geen een die gebruik maakt van UDP, maar een alternatief voor UDP (en TCP).
Het is een alternatief voor TCP dat geÔmplementeerd is middels UDP.
udp is van nature veel sneller dan tcp. Immers worden er geen ack's teruggestuurd waarop gewacht moet worden. De hogere lagen moeten dan echter wel voor de juiste checksum e.d. zorgen anders komen de bestanden verminkt over.

ER zijn ook applicaties waarbij dat niet uitmaakt. Voice of Video bijvoorbeeld is het beter om een hikje te ervaren dan een retransmit waarbij het hele beeld stilstaat. Ook bij realtime uitzendingen wordt veelal udp gebruikt omdat men niet op de ack's van de buren wil wachten.
Was mooi geweest als ze UDP ook in de vergelijking hadden meegenomen
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.
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.
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.
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.
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.
UDP is ook gebruikt bij gaming?
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.
Je throughput wordt gelimiteerd door je Gb aansluiting, niet door TCP. 108 MB/s gemiddeld zit aardig in de buurt van de limiet.
108 Megabyte/s is > 800Megabits/s dus aardig in de buurt van 1 Gigabit.
Nee. De latency die die paar hops in je huis met die minimale kabelafstanden oplevert ga je niet drastisch kunnen verlagen. Dan heb je het over een totaallatency van een paar milliseconden.

Als je een pad van 20 hops over de halve wereld hebt met in totaal 600ms latency heb je hier wellicht wat aan. Maar dan nog is het alleen zinnig voor een applicatie die en latencygevoelig is en hoge betrouwbaarheid eist. En je moet het niet simpel binnen je applicatie kunnen oplossen voordat je middleware van een derde inzet.

Een gemiddelde throughput tussen NAS en PC van 108MB, en dus 864Mbit is erg netjes voor een thuisoplossing hoor. Daar gaat dit niet bij helpen. Wellicht dat je sessie iets sneller groeit naar die maximale throughput maar ook daar zou ik niet op rekenen in kleine netwerken op korte afstanden.
(en ook @ mensen boven me)
Vergeet het verschil tussen megabyte en mebibyte niet, he! File transfers worden over het algemeen altijd gemeten in mebibyte/s oftewel MiB/s.

Een Gigabit verbinding heeft een throughput van 1 miljard bits/s. Het maximaal haalbare is dan ook 1.000.000.000 / 8 / 1.024 / 1.024 = ~119,2 MiB/s, maar dat is bruto (dus inclusief overhead van de packets zelf)

Met een throughput van 108MiB/s zit je al aan de 108 * 1.024 * 1.024 * 8 / 1.000.000 = ~906 Mbps netto (dus zůnder overhead).
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 sp00kler op 30 januari 2013 13:50]

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.
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
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?
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 30 januari 2013 13:53]

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 30 januari 2013 13:58]

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 30 januari 2013 14:11]

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)
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.

Op dit item kan niet meer gereageerd worden.



Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBWebsites en communities

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True