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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 68 reacties, 15.437 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)

Reactiefilter:-168068+144+26+30
Moderatie-faq Wijzig weergave
Hoeveel van dit soort protocollen op basis van UDP zullen al niet gemaakt zijn?

BitTorrent Inc. was met zijn Micro Transport Protocol (ĶTP) er al veel eerder mee.
Kijk deze kant moeten we op :D
De ervaring leert dat:

1. Je uit moet kijken als bedrijven met claims als 'x keer zo snel!!' smijten
2. Je hier waarschijnlijk nooit meer iets over hoort.

Volgende bericht.
Ik ben niet verbaasd dat dit juist bij Fujitsu vandaan komt.
Een een vorig decennium was daar een Duits bedrijf Softlab dat zijn Maestro II workbench verkocht aan grote bedrijven, ook in Nederland. Dit tool maakte gebruik van een repository op een Unix omgeving die communiceerde met (windows) desktop clients voor de user interface: Een typische client server opzet. Deze communicatie was steevast UDP, want... dit was veel efficienter dan TCP. Alleen moest (extra) error checking aan de client side uitgevoerd worden op de ontvangen data.
De ENABLER repository technologie (object-database) is overgegaan van Softlab naar Fujitsu. Of de Maestro II is meegekomen weet ik niet. In ieder geval heeft Fujitsu goed gekeken naar de Duitse oplossing en deze nieuw leven ingeblazen. Maestro II was gebaseerd op een eigen "operating system" dat bovenop DOS draaide, met eigen tekst-vensterinterface en memory management. De extra benodigde error checking op de client zat dus in de maestro client.
En nu dus heeft Fujitsu kans gezien dit UDP concept opnieuw leven in te blazen.
PropriŽtair: betekent dit dan in de realiteit dat dit alleen bruikbaar is bij Fujitsu-apparaten onderling, of zouden ook andere fabrikanten dit gaan implementeren (al dan niet tegen licentie)?

Ik snap dat R&D geld kost en dat ze dit terug willen zien maar je hoort vaker van nieuwe protocollen die nooit aan de man komen. Zelfs 'open' standaarden en protocollen doen er jaren over om een beetje geaccepteerd te worden.

[Reactie gewijzigd door Passeridae op 30 januari 2013 13:40]

Het Japanse bedrijf wil zijn netwerkprotocol aan andere bedrijven gaan verkopen in de vorm van middleware.
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.
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.
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.
Maar hoe handelt hij dan de "lost packages" of is "lost" gewoon lost...?
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]

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

Het versturen van deze correctie-data (PAR) is gewoon extra data. De overhead daarmee is dus ENORM!
Dat werkt niet als je maar weinig data (een pakketje) te versturen hebt.
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.
Leuk hoor, zo'n protocol. Jammer dat het dus propriŽtair is, wat in de echte wereld betekent dat het nooit groot kan worden, of 'net zo groot' als TCP/IP en UDP/IP...
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.
udp is van nature veel sneller dan tcp. Immers worden er geen ack's teruggestuurd waarop gewacht moet worden.
Misschien tijd dat iemand het concept "sliding window" uitvindt.
Dit is zeer interessante voor thuis toepassingen.

Bij het lezen van dit artikel dacht ik direct aan de troughput van mijn NAS (eigen bouw o.b.v. atom) wat nu gelimiteerd wordt door TCP ( gemiddelde troughput van 108 MB/s) op een gigabit aansluiting.

Ik zou dit zeker uit willen proberen binnen mijn thuis netwerk, indien dit beschikbaar komt.
SCTP al eens een draai gegeven?
Tuurlijk. Want 108 MegaByte/sec halen over een 1 Gbps netwerk is wel erg slecht. Dit nieuwe protocol is wel 30x sneller. Dus dan kun je mooi 3240 MegaByte/sec halen ! Feest !

Zonder dollen: 108 MBps = 864 Mbps = 0.864 Gbps. Als je in gedachten houdt dat je altijd wat overhead hebt door protocol headers (minimaal 58 bytes voor iedere 1460 bytes aan data = 3.8%), dan zit je al aardig bij de maximale haalbare snelheid. Ik snap niet waar je over klaagt. Ik zou ook eerst eens kijken dan de bottleneck van je HDD (of zelfs SSD). En ook een Atom is niet al te snel, dus dat zou ook een beperkende factor kunnen zijn.
Dat zal dan bijna niks uitmaken, binnen je thuisnetwerk heb je echt geen last van packet loss en/of latency waardoor tcp relatief langzaam kan zijn.
(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).
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.
108 Megabyte/s is > 800Megabits/s dus aardig in de buurt van 1 Gigabit.
Je throughput wordt gelimiteerd door je Gb aansluiting, niet door TCP. 108 MB/s gemiddeld zit aardig in de buurt van de limiet.
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...).
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.
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.
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?
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.
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 30 januari 2013 15:16]

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 30 januari 2013 17:44]

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True