Snelle concurrent voor TCP ontwikkeld

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.

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

Reacties (69)

[beany]

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?

[kalizec]

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.

[Exirion]

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.

[Jheroun]

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.

[QuarkuS]

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.

[jochemd]

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.

[VisionMaster]

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.

[Verwijderd]

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

[Jheroun]

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.

[Verwijderd]

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.

[Verwijderd]

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

[JeroenB]

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.

[CmdrKeen]

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

[Myrdhin]

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.

[Verwijderd]

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.

[Jheroun]

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.

[Verwijderd]

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.

[Verwijderd]

Interessant. Voor meer details: www.csc.ncsu.edu/faculty/rhee/export/bitcp.pdf

Kern van het verhaal is, dat ze spelen met de grootte van zgn. ontvangstwindows in het TCP-protocol. Het huidige protocol is vooral gericht op de oude situatie waarin datatromen veel kleiner waren (windows worden langzaam vergroot en snel verkleind). Nieuwe (theoretische) voorstellen proberen in te spelen op grotere datastromen (sneller vergoting, langzamere verkleining van de windows). Deze protocollen zijn echter vaak weer slechter als tegelijk ook kleine datastromen meeliften. BI-TCP probeert een compromis te vinden. Dit compromis kost natuurlijk wel wat uitzoekwerk, en wat ik bv. niet vond in het verhaal is de vraag of de overhead voor hun binary search altijd opweegt tegen de kosten.

Het artikel vergelijkt 4 (geen 6) protocollen, zonder de nu gebruikte TCP versie. De getallen in de samenvattingen zijn niet terug te rekenen; we missen gegevens. Wat niet verbazend is; hoe netjes in het artikel ook een testomgeving gemaakt wordt, de werkelijkheid kan nog veel vreemder zijn. Of alles dus echt zo werkt moeten we maar afwachten (het schrijven van goede protocollen is erg moeilijk).

Het verhaal gaat niet in op de werking van het onderliggende IP-protocol, en voor zover ik weet richt IPv6 zich ook op grotere datastromen. Die getallen 6000 en 150.000 konden wel eens wat kleiner worden met IPv6...

[Verwijderd]

Ik vind het nogal een vaag verhaal, waar een aantal tegenstrijdigheden in zitten...

1 - Er wordt gesproken over een opvolger van TCP, maar ook over verbeteringen in routering. Routering wordt gedaan door IP, daar heeft TCP niks over te zeggen. Daarbovenop wordt de routering vaak beinvloed door de manier waarop het routeringsprotocol (BGP, OSPF, RIP) het netwerk 'ziet', daar kan je niks aan doen met een opvolger van TCP.

2 - Er wordt gesproken over "BIC can achieve speeds roughly 6,000 times that of DSL and 150,000 times that of current modems."... nu heeft men het inneens over laag 1... hoe kan je de efficientie van laag 1 beïnvloeden met een nieuw laag 4 protocol? Deze snelheden zijn ook met TCP te halen. Waarschijnlijk zit de verbetering er in dat BIC beter in staat in de volledige bandbreedte van een kanaal te benutten dan TCP; maar de manier waarop het hier beschreven wordt lijkt het net alsof we met BIC 6000x snellere ADSL verbindingen krijgen, en dat is dus pertinent niet waar.

[QuarkuS]

Die press release staat inderdaad bol van de rarigheden, maar als je de abstract van de paper leest, dan klinkt het ineens een stuk beter.

Ze doen dus niks aan routering, maar houden zich bij de transport layer. Ze verbeteren de congestie eigenschappen van het transport layer protocol. Dit heeft dus niks met routering te maken.

En inderdaad wordt de lijn fysiek niet plotseling sneller, hij wordt alleen efficienter benut als de congestie wordt tegengegaan.

[Verwijderd]

Ze doen dus niks aan routering, maar houden zich bij de transport layer. Ze verbeteren de congestie eigenschappen van het transport layer protocol. Dit heeft dus niks met routering te maken.

De ideale windowsize die ze adaptief zoeken met hun congestion control protocol is afhankelijk van het pad dat de data volgt. Dit pad bestaat vnl. uit routers en kabels, waardoor het stiekum dus toch met routering heeft te maken. Zij het op een wat abstracter niveau.

Dit is een goed idee, aangezien er niets aan de bestaande infrastructuur hoeft te worden veranderd.

[Verwijderd]

Ik heb inderdaad het idee dat het persbericht een beetje opgeleukt is om wat extra publiciteit te krijgen... "Universiteit ontwikkeld Nieuw netwerk protocol" is natuurlijk veelste saai... "Mogelijk binnenkort 6000x zo snel Internetten" is al een veel betere kop... dat dat niet helemaal waar (lees: helemaal niet waar) is, is dan van ondergeschikt belang...

[Verwijderd]

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

[mr._Anderson]

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 ?

[loodgieter]

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

[freaky]

OSI niet doorgebroken? Uh ok, tuurlijk.

[VisionMaster]

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

[mr._Anderson]

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

[Verwijderd]

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

[VisionMaster]

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

[Bl@ckbird]

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.

[freaky]

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.

[Verwijderd]

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

[Verwijderd]

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

6000x hoger

[Verwijderd]

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.

[kalizec]

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.

[VisionMaster]

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

[Verwijderd]

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.

[kalizec]

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.

[Maestro.mosjuh]

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

[Gummbahla]

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.

[QuarkuS]

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.

[Jheroun]

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.

[YakuzA]

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 ???

[kalizec]

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.

[Flipmo2K]

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

[Verwijderd]

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.

[Flard]

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?

[kalizec]

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.

[Oceria]

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*

[Eärendil]

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.

[Verwijderd]

Het is allemaal heel leuk en aardig dat ze weer een nieuw protocol hebben gemaakt, maar zelfs IPv6 is nog lang niet overal ingevoerd. Lijkt me dat ze eerst IPv6 gaan doen en dan dat BIC ding

Denk dat dit wel een jaartje of 2 a 3 duurt voordat het uberhaupt wordt opgepakt en dan nog een jaartje of 2 voordat het echt geïnplementeerd wordt.

(offtopic)
hoe zit het eigenlijk met Cisco en IPv6?
(/offtopic)

[Jheroun]

Jongens jongens. Het stikt hier weer van de klepels maar de klok heeft geloof ik nog niemand gevonden :-)

IPv6 gaat over IP (doh), een laag 3 protocol dat ook adressen behelst, en met de informatie welke groep er waar hangt proberen we met BGP (dat overigens over TCP loopt, maar das een ander verhaal) het internet een beetje bij elkaar te houden.

(correct me if I'm wrong, mijn kennis houdt een beetje op ergens in laag 4)Als jij een ip connectie opzet met iemand aan de andere kant van de wereld kunnen jullie daar met zijn tweeen fijn bic-ip/whatever over babbelen, dat boeit niet. IP en routering zorgt ervoor dat wat jij verstuurd bij die andere persoon aankomt, wat er in die pakketjes zit doet er onderweg niet toe.

En wat wil je weten over cisco en ipv6? Wel eens van google gehoord? Bijna alle cisco zut ondersteund gewoon ipv6, net als alle juniper spullen.

[ajslaghu]

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.