Hoofdcategorieën
Device Settings

Snelle concurrent voor TCP ontwikkeld

Door Remy Bergsma, woensdag 17 maart 2004 10:30
Bron: NCSU, submitter: damanseb, views: 21.035

Onderzoekers van de Universiteit van North Carolina hebben een nieuw netwerk-protocol ontwikkeld waarmee datatransfer-snelheden te behalen zijn die tot 6000 keer hoger liggen dan de huidige combinatie van DSL met TCP/IP. Het nieuwe protocol heet BIC-TCP, wat staat voor Binary Increase Congestion Transmission Control Protocol. Uit verschillende experimenten waarbij onder andere de stabiliteit en de schaalbaarheid van het nieuwe protocol en zes andere protocollen werden getest, bleek het BIC-TCP protocol telkens bovenaan de ranglijsten te eindigen. BIC-TCP werkt door heel snel op netwerken te zoeken naar de snelste manier om data van punt A naar punt B te sturen, een zogenaamde binary search approach. Op deze manier kan de beschikbare bandbreedte van netwerken optimaal worden benut, terwijl er ook een balans is gezocht om andere protocollen niet van hun bandbreedte te beroven. Netwerktoepassingen zoals online multiplayer-games, real-time environmental monitoring en telemedicine kunnen hierdoor veel efficiënter werken.

snel internetDe waarde van dit nieuwe protocol zal vooral voor wetenschappelijke onderzoekslaboratoria groot zijn: de vergaarde data van onderzoeken kan met het BIC-TCP protocol veel sneller van de onderzoekslocatie naar analyse-laboratoria gezonden worden. Het huidige TCP/IP protocol voldoet niet meer aan de grote honger naar bandbreedte van dergelijke toepassingen, terwijl de netwerken zelf dat wel aankunnen. Met het BIC-TCP protocol moet daar eindelijk verandering in komen:

The problem, Rhee said, is the inherent limitations of regular TCP. "TCP was originally designed in the 1980s when Internet speeds were much slower and bandwidths much smaller," he said. "Now we are trying to apply it to networks that have several orders of magnitude more available bandwidth." Essentially, we're using an eyedropper to fill a water main. BIC, on the other hand, would open the floodgate.
Volgende 10:50 Shuttle gaat volledige PC-systemen leveren
Vorige 10:26 Toshiba vestigt record met kleinste harddisk
Advertentie

Reacties

«  1  2  »

Opzich heel erg positief, alleen jammer dat ik nu net bezig ben met het TCP protocol aan het uitpluizen :'(

Zal de school is vragen of ik dat nu mag overslaan :D

Als jij volledig weet hoe het TCP protocol in elkaar zit, zal het wel minder werk zijn om het BIC protocol te leren, denk je ook niet :P ?

Hoop dat dit doorbreekt. en niet zoiets word als het OSI model wat opzich ook wel een goed idee was maar ook niet werd doorgevoerd.

als BIC-TCP ook uit vier lagen bestaat zal er inderdaad niet zo veel meer geleerd hoeven te worden :)

OSI niet doorgebroken? Uh ok, tuurlijk.

Als je voldoende weet van networking in de praktijk (ik ben ook geen Uber-Held), dan gebruik je het OSI model niet ...
nofi ... maar het is een model dat een representatie geeft dat niet overeenstemd met de werkelijkheid.

Er is in Nederland ook al flink wat onderzoek aan de gang omtrent het te gebruiken protocol. Precies het aangestipt argument wordt hier benadrukt dat opgelost zou moeten zijn. Namelijk ... als je op een lijn zit met een zeer aggressieve TCP/IP sender op de lijn, dan drukt die de bandbreedte van ieder ander tot nagenoeg op de grond.
Als BIC-TCP dit probleem heeft opgelost, dat andere protocollen die verwant zijn of oorsprong hebben uit TCP/IP ook hebben geprobeerd op te lossen, dan kunnen de snelheden van de hedendaagse netwerken weer wat worden opgekrikt :)

IPv6 krijgt toch de mogelijkheid een prioriteit niveau mee te geven aan packets. Dat zou het toch ook kunnen oplossen (deels). Of zit ik er dan volkomen naast?

update..
ik realiseerde me het toen ik op de knop drukte.. haalde IP en TCP ff door elkaar heen... mijn excuses

Ik kan het fout hebben hoor, maar een protocol is maar 1 laag van het OSI model....

Yup, dat klopt niet helemaal ;)
Sommige protocollen en handelingen die het doet heeft uitwerkingen op meerdere lagen van het OSI-model, dus zou het model al snel niet meer kloppen, omdat ieder protocol zijn taak zou moeten hebben. Wat het dus niet helemaal heeft ;)

IP World vs OSI World
OSPF vs IS-IS
SNMP vs CMIP
TCP vs TP
IP vs CLNP
IP adres vs NSAP adres
Datacom vs Telecom

OSI protocollen gebruiken de volledige 7 laags stack,
IP doet hetzelfde in 4 lagen.

Correct, de gemiddelde systeembeheerder zal nooit denken in OSI termen.

De gemiddelde hardware boer/protocol ontwikkelaar gebruikt het echter wel.

Dat is net zoiets als zeggen ja de orange book hebbie ook niet nodig. Toch word ieder CD-tje via die standaarden gefikt zo'n beetje. Dus is het wel degelijk mainstream en dus doorgebroken. Pin me ff niet vast op de kleur van het boek, het is een tijdje geleden.

Video2000 was ook beter dan VHS, toch is VHS de standaard geworden.

TCPIP is reeds de standaard, dus ik vrees dat er niets aan zal veranderen. Trouwens, tot 6000x sneller zegt niet zo heel erg veel...

Zo dat klinkt zeker leuk, maar het zal zeker wel weer even duren voor dit echt kan worden toegepast?

6000x hoger O+

Lijkt me daarom ook verstandig dat ze het combineren met IPv6 dus de zelfde manier van data transport maar dan met IPv6 adressen want er is nog steeds niet echt een vaste standaard met IPv6.

IPv6 is wel een vaste standaard. Het is alleen nog niet globaal ingevoerd en is ook nog niet overal geïmplementeerd.

De standaard zelfs echter is qua specificaties gewoon vast hoor.

Zover ik begrijp uit de tekst is er een vernieuwing van TCP in de vorm BIC-TCP, ipv4 of ipv6 onafhankelijk ... lijkt mij

Wat ik me afvraag is wat voor aanpassingen er gedaan moeten worden. Is dat alleen op applicatie niveau? Of moeten routers onderweg ook aangepast worden? En hoe zit het met IPv6 ?

Ofterwel: hoeveel moeite kost het om dit te implementeren?

Ze hebben het over een alternatief voor TCP, dus ik neem aan dat het allemaal nog steeds bovenop IP draait. Of dat dan IPv4 of IPv6 is lijkt me triviaal, aangezien v6 backwards-compatible is.

Vraag je beter af of het rendabel is... Lijkt mij wel, als het inderdaad 6000 maal sneller is ;)

Je leest het verkeerd. Er staat niet dat het 6000x sneller is maar dat je er 6000x hogere snelheden mee kunt halen. Het standaard TCP protocol heeft vanwege zijn manier van transfer (sliding windows) problemen als er grote hoeveelheden data verstuurd worden. De snelheid loopt tegen de limiet van het protocol aan.

Hoewel het er niet echt duidelijk in staat, staat dit waarschijnlijk systeem los van het adresseringssysteem. Het protocol heeft eerder betrekking op de manier hoe er data verstuurt wordt, wanneer bevestigt moet worden en hoe groot packets mogen zijn. Tevens lijkt het er op dat het een stuk slimmer is qua routering.

Dat betekent echter ook automatisch dat tussenliggende routers geupdate zouden moeten worden om ditzelfde voordeel te halen. (Lijkt mij dan).

[EDIT]

Kort samengevat:
-Slimmere routering.
-Slimmere (groter) packetgroottes.
-Minder beperkend qua vraag/antwoord/controle.

Juist. Ze misleiden de boel aardig vind ik. Het feitelijke transort protocol staat los van de routering, en ze noemen het hier in 1 adem. Als je TCP combineert met een efficientere routering dan zul je ook een snelheidsverbetering realiseren.

Het protocol dat zij voorstellen is geen concurrent voor TCP want het is appels met peren vergelijken. Ze hebben een totaal systeem ontwikkeld, inclusief routing.

Ze misleiden de boel inderdaad behoorlijk, maar als je de abstract leest wordt het wel duidelijk. Ze doen dus niets aan de routering, alleen aan congestion control. Het is dus wel een TCP vervanger, en onafhankelijk van de netwerk laag (IPv6 of IPv4). Trouwens, IPv6 is nou niet echt helemaal backwards compatibel. Je kan het alleen wel dual-stack draaien.

Nee, het is geen TCP vervanger (de presentatie is op InfoCom niet voor niets in het "TCP Enhancement" track ingeroosterd).
TCP regelt, naast een aantal andere dingen, de wijze waarop geprobeerd wordt de throughput van een verbinding te optimaliseren. Daarbij moet je denken aan een optimalisatie van de pakketgrootte, een optimalisatie van de resend-strategie, hoe lang er gewacht wordt op een ACK etc.
Het algoritme dat binnen TCP daar nu voor gebruikt wordt is bij hoge latency en snelle verbindingen vaak suboptimaal, waardoor zelfs over 10 Gb verbindingen de feitelijke throughput zelden boven de paar honderd MB uitkomt. Waar het hier over gaat is dat er een nieuw algorithme is bedacht dat specifiek voor snelle, hoge latency netwerken zorgt dat de feitelijke benutting van de netwerkcapaciteit veel hoger wordt. Daarmee valt dit BIC-TCP in de zelfde categorie als FAST-TCP wat ongeveer een jaar geleden een vergelijkbaar juich-artikel op Tweakers ten deel viel en dat ook in de zelfde track behandeld wordt.

Dat verhaal over XGe verbindingen gaat alleen op als je over die link maar 1 tcp flow hebt lopen. Bijvoorbeeld wanneer je tussen 2 applicaties over een dergelijke link praat. Zolang er nog geen servers zijn met 10Ge koppelingen (alssof een harddisk dat bijhoudt :-) doet dat er niet zoveel toe.

Een XGe koppeling loopt meestal tussen routers of switches, daar gaat wel meer dan 1 stroom tegelijk overheen. Gelukkig maar anders zou die 7G niet over onze XGe link passen :-)

Maar voor sommige toepassingsgebieden kan zoiets snel noodzakelijk worden. Als doctoren in Nederland in real time cat scans die in australie gemaakt zijn willen bekijken moet er wel meer dan een paarhonderd meg tegelijk per seconde van endstation naar endstation kunnen.

EDIT:

Meer research leidt tot het volgende begrip van wat ze voorstellen.

Die 6000 en 150.000 zijn alleen vergelijkingsnummertjes tov dsl en modems die niets te maken hebben met dsl en/of modems. Mensen die hierover babbelen lezen niet goed of interpreteren verkeerd :-) Het blijft overigens wazig gebrabbel, alsof ze een marketeer in de hand genomen hebben om dit te presenteren. Wat ze zeggen is hetzelfde als "we hebben een snelweg ontwikkeld (bic-tcp) waar je overheenkan met 6000 keer de snelheid van een brommer (dsl)". Dat klopt, maar dat wil nog niet zeggen dat die brommer die snelheid zelf kan halen.

Die snelheidsverhoging gaat op voor endstation naar endstation verbindingen waarbij beide eindpunten een dikke netwerkkaart hebben (Gb/s ofzo). Zoals je al zei gaat er over 1 tcp stream momenteel erg weinig, ook al zijn de dingen die uiteindelijk aan elkaar gekoppeld worden erg snel. BIC brengt daar verandering in.

Die paar honder meg is eerder rond de 15GB
Hier in Nederland is er ook zo'n setup.
10GbE kan wel tot bijna het maximum worden benut multi-stream, maar single stream kom je al gauw niet boven de 6.4 Gb uit ivm de throughput van je mem naar je 10GbE NIC.
Maar dat ter zijde ... je kan die lijn wel vol krijgen met een getweakte TCP/IP. Optimized en met een aggressieve stack kan jij heel snel verzenden en de lijn zeer goedbenutten.
Je drukt alleen de andere gebruikers er uit.
Bij Lambda networking is dat niet zo erg, omdat je dan een gereserveerde link hebt van end-2-endpoint. Dan kan je zo hard gaan als je wilt.
www.netherlight.nl voor wat onderzoeksdingetjes hierover.

Daarnaast heb je vaak een probleem met je PCI bus. Dodelijk voor Gbit ethernet.

Routers doen geen tcp (in ieder geval niet primair), routers doen IP.

Echt, het wordt tijd dat iedereen voordat hij iets over dit soort onderwerpen mag roepen een basis 'hoe werkt het internet' cursus moet volgen :-)

Een router is een IP apparaat, osi laag 3. TCP draait bovenop IP, in osi laag 4.

Routeren is het pad van a naar b maken. tcp'eren is zorgen dat je data ook goed aangekomen is. Als je tcp aanpast hoeft ip niet te veranderen. Even een vergelijking: Het maakt niet uit wat (tcp) er in een envelop (ip) zit. Hij kan toch wel verstuurd worden.

Dus, routers die niks op laag 4 doen worden hier niet door geraakt. Het zal bij uitbreidingen vooral gaan om access machines die op laag 3 en 4 werken en servers.

Zie de post van Yoshi en mijn reactie daarop voor info over wat bic ongeveer doet.

Hoe kan het in godsnaam dat iemand die iets probeert uit te leggen over het artikel, gemod wordt met off-topic? |:(

Alles leuk en aardig, maar die mooie OSI3 en OSI4 laag zijn in de praktijk sterk in elkaar geintegreerd. TCP/IP zegt men.

Net zoals de mooie OSI5, OSI6 en OSI7 lagen; allemaal 1 pot nat.

Het huidige TCP/IP protocol voldoet niet meer aan de grote honger naar bandbreedte van dergelijke toepassingen, terwijl de netwerken zelf dat wel aankunnen.
Hardwarematig hoef je in principe niets te veranderen.
Er zal misschien nieuwe firmware nodig zijn om je router er mee overweg te laten kunnen, maar dat is op zich ook niet echt spannend.

Hoewel ik denk dat het voor het gewone bedrijfsleven en de partikulier dusdanig lang duurt nog dat er gebruik van gemaakt gaat worden, dat de hardware zowiezo toch al vaak vervangen moet worden.

Grappig dat je voor een domme vraag tegen woordig 4 mod punten krijgt !!!

terwijl somige slimme antwoorden compleet worden weg gemod.

Ik heb het idee dat er steets meer mensen zonder enige kennis van zaken puur op het 'Emo' gehalte modden.

Mijn idee. Dat is het gevolg van de onwetende massa :-)

Een vroege reactie die compleet fout is maar een op zich logisch verhaal lijkt te houden krijgt, onafhankelijk van de waarheidswaarde, veel plussen. Als mensen niet beter weten zijn ze kennelijk al snel geneigd verkeerde dingen te geloven. Vanaf dat moment hangen ze die ook als waar aan en dus wordt alles dat daarvan afwijkt aangevallen. Hmm, klinkt historisch gezien best bekend.

In het land der blinden is eenoog koning.

Op zich een mooie vooruitgang, maar ik ben benieuwd óf dit ooit de standaard zal worden, en zo ja: hoe lang het nog zou duren voordat het echt standaard is.

Probleem is namelijk dat álle netwerkhardware vervangen moeten worden (of d.m.v. van firmware upgrades).

Ik bedoel: als het al té moeilijk is om het SMTP te vervangen door een veiligere variant, hoe wil je dan een compleet internet-protocol vervangen?

Uit het bericht begrijp ik echter dat het alleen om het protocol gaat en dat de netwerken zoals die er nu liggen die extra snelheid over het nieuwe protocol makkelijk aankan. Zo geredeneerd zou de hardware niet veranderd hoeven te worden. Alleen de netwerk protocollen van OS en routers zou dus veranderd moeten worden. Net als bij de invoering van IPv6
Correct me if I'm wrong

*edit*
Nou, zoals hierboven staat dus ;)
*/edit*

*edit 2*
Sorry van die l**ige typo (typen blijft moeilijk).
*/edit 2*

Dit werkt op een ander niveau, de meeste routers weten namelijk niets van protocollen boven IP, ze schuiven alleen de IP pakketjes naar de host met het goede IP-adres, en alleen de doel-host kijkt naar de TCP-headers.

Het voordeel is dat je in dit geval het protocol langzaam in kunt voeren en intussen gewoon de huidige zaken kunt tunnelen.

Zo hoef je dan namelijk in tegenstelling tot bv SMTP niet globaal een nieuw protcol in te voeren.

[EDIT]

Ter voorbeeld: SurfNET draait (naar ik meen) native ook gewoon IPv6 en daar tunnelen ze IPv4 over. Het is dus mogelijk om gewoon gefaseert in te voeren.

Snel zoeken naar snelste verbinding tussen A en B is op een lokaal netwerk wel mogelijk. Vraag me wel af of dit op te schalen is naar WWW-formaat, zijn wel heel veel verbindingsopties mogelijk dan. Andere vraag is hoe afhankelijk de snelheden zijn van de infrastructuur die wordt gebruikt (zitten veel knooppunten op www).

Vraag me wel af of dit op te schalen is naar WWW-formaat, zijn wel heel veel verbindingsopties mogelijk dan.
Er staat niet voor niets dat het in eerste instantie veel nut heeft in bv. universiteitsnetwerken. En het aantal verbindingsopties valt op zich wel mee: je kunt tegenwoordig binnen tien hops naar de andere kant van de wereld. En het protocol is natuurlijk niet zo ontworpen dat het alle mogelijke verbingenen apart gaat bekijken.
Andere vraag is hoe afhankelijk de snelheden zijn van de infrastructuur die wordt gebruikt
Welke snelheden bedoel je? Van de infrastructuur zelf of van TCP? Dat laatste is juist ontworpen om op een onbetrouwbaar internetwerk een betrouwbare end-to-end bytestroom te krijgen. Daarbij wordt uiteraard rekening gehouden met de zeer uiteenlopende topologieen, bandbreedten, pakketgroottes, etc van al deze netwerken. Deze flexibiliteit heeft uiteraard invloed op de performance van het protocol.

Universiteitsnetwerken hebben vaak een koplopersrol, als het daar een succes blijkt en breed gebruikt wordt dan is het straks leuk op een afgesloten netwerk, maar met de ontwikkeling dat de meeste info real-time on-line wordt verzameld stokt het snelle netwerk bij iedere koppeling naar een langzamer extern netwerk. Het zou dus interessant zijn om die snelheden op te kunnen schalen naar meerdere gekoppelde netwerken en uiteindelijk het www.

Als er wordt opgeschakeld dan zou de grote varieteit aan hardware wellicht een bottleneck kunnen zijn voor een snel protocol.

6000x sneller, dat zou toch beteken dat je 100mbit switch vervangen moet worden door een 600 Gbit switch.... denk niet dat die er zijn. Hier zal dus wel speciale hardware voor nodig zijn, en dus niet voor het gemiddelde mkb/thuisgebruiker zijn weggelegd.

De 6000x sneller melding in het stuk slaan op het feit dat TCP niet goed in staat is de volle bandbreedte van een 1Gbit of 10Gbit lijn te vullen omdat teveel tijd verdaan wordt met vraag/antwoord/controle spelletjes.

6000x 256kbit (DSL) is 1,5Gbit

Dus daar zit je 6000x sneller in.
Niet in het feit dat je lokale LAN weer tig keer sneller wordt. Het wordt gewoon efficienter gebruikt.

*volgens mij* niet

volgens mij maakt het protocol juist gebruik van bestaande systemen, en gaat het sneller door:
- betere routing (data van zwolle naar enschede niet via amsterdam sturen bijvoorbeed)
- misschien minder overhead (minder controlepaketten)

betekend dat de hoeveelheid data niet (veel) minder word; aleen het legt een kortere afstand af.

Het gaat hier niet om de totaal doorgevoerde hoeveelheid data die veranderd, maar de samenstelling ervan. Met dit nieuwe protocol beoogt men minder control-data (data om de verbinding in stand te houden) te versturen en meer bandbreedte over te houden voor de 'echte' data.

Allemaal fout. Dit protocol is bedoeld om congestie tegen te gaan. De fysieke snelheid van de lijn gaat dus niet omhoog (hoewel ze dat wel suggereren). Ook wordt er niet minder overhead gegenereerd of de samenstelling veranderd. Alleen de beschikbare bandbreedte wordt beter benut door congestie te voorkomen. Het gebruik van de lijn op transport layer level wordt dus efficienter.

6000 keer sneller != 6000 keer meer bandbreedte. Het gaat om TCP dat sneller wordt niet je verbinding op zich.

(fictief voorbeeld) Stel je hebt een adsl verbinding die 2Mb/s downstream heeft. Als het normaal 10 seconden duurt voordat je download op 2 Mb/s loopt zal het, volgens de mensen van dit nieuwe protocol, nu 0,00167 duren voordat je verbinding op die snelheid loopt.

Dat heeft dus geen zak te maken met de hoeveelheid data die er over die lijn gaat.

Netwerktoepassingen zoals online multiplayer-games

Dit snap ik eigenlijk niet echt, aangezien je bij multiplayer games juist alleen hinder zal ondervinden van TCP. Ik verkeerde in de veronderstelling dat dit juist allemaal via UDP ging omdat je bij online games toch nix meer hebt aan pakketjes als ze een aantal secondes te laat aankomen, dan wil je ze liever droppen ???

TCP = veilig en betrouwbaar.
UDP = onveilig en onbetrouwbaar.

UDP is voor streaming ideaal, daar maakt het niet uit als er af een toe een framepje wegvalt. Bij multiplayergames maakt dat wel zeker wat uit, je krijgt gewoon lag dan...

UDP heeft voor multiplayer games ook de voorkeur.
Dit omdat bij TCP aflevering van alle data en ook nog eens in de juiste volgorde wordt gegarandeerd. Packetloss betekent dan niet alleen het verliezen van data, maar ook het blokkeren van alle volgende data tot het verloren pakket alsnog wordt afgeleverd.
Bij UDP wordt het aantal keren dat pakket aankomt niet gegarandeerd (meestal 1x, maar soms niet en soms meerdere keren), en de volgorde ook niet. Meestal is die zoals het is verzonden, maar niet altijd. Het is dus de kunst om een spel hier robuust voor te maken. Dat is extra werk, maar je hebt het wel gedrag in de hand. Dit in tegenstelling tot de problemen bij TCP.
Voor realtime multiplayer heeft UDP dus de absolute voorkeur.

Maar als je een protocol hebt wat bij het routeren juist probeert te zorgen dat dit zo min mogelijk gebeurt (packets die er seconden over doen) door hier bij het uitkiezen van de route rekening mee te houden. Dan heb je daar wel degelijk baat bij.

snelle netwerk protocollen: een beetje oud nieuws (een paar jaar oud) . het wordt gebracht als of het iets totaal nieuws is. er zijn allang varianten op tcp zoals o.a. fast tcp.

klinkt veelbelovend maar euh denk je dat CISCO daar nou gaat aan meewerken ?
Ik vrees dat dit nog jaren gaat aanslepen eer men tot een consensus komt zodat het gelijk voor iedereen werkt.
En ik ben ook van mening dat men hier een beetje appelen met peren aan het vergelijken is want ik zie het verband ook niet tussen TCP en routering.
Het zou beter zijn als men BGP/TCP vergelijkt met BIC/tcp!
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 10:50 Shuttle gaat volledige PC-systemen leveren
Vorige 10:26 Toshiba vestigt record met kleinste harddisk
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011