Wiskundig coded tcp-protocol zou wifi en lte flink versnellen

Wetenschappers aan diverse universiteiten zeggen dat met behulp van een wiskundig algoritme de beschikbare bandbreedte op lte- en wifi-netwerken met een factor tien vergroot kan worden. Het coded tcp-algoritme zou een alternatief bieden voor de huidige inefficiënte methode om met packet loss om te gaan.

Aan het onderzoek naar een nieuw algoritme, dat coded tcp is genoemd, is gewerkt door wetenschappers van MIT, de universiteiten van Harvard, Porto en München, en Caltech. Bij de huidige tcp-netwerktechnologie zorgt het mechanisme om packet loss te ondervangen voor lagere snelheden en een inefficiënt gebruik van de beschikbare bandbreedte op met name draadloze netwerken omdat een verloren pakketje opnieuw verstuurd moet worden van zender naar ontvanger. De onderzoekers stellen dat zij met behulp van een relatief eenvoudig wiskundig algoritme daar iets op hebben gevonden. Door niet langer uitsluitend losse datapakketjes, maar een serie datapakketten te bundelen en deze te voorzien van een beschrijvende wiskundige vergelijking, hoeft de ontvanger bij een verloren gegaan pakketje deze niet opnieuw op te vragen. De ontvanger kan immers via de meegestuurde vergelijking de inhoud daarvan reconstrueren.

De onderzoekers stellen dat het gebruikte coded tcp-algoritme niet complex is en alleen lineaire berekeningen vereist, en daarom relatief weinig processorkracht nodig heeft. Hierdoor zou de technologie goed bruikbaar kunnen zijn op allerhande apparaten, waaronder smartphones en routers. Bovendien kan het algoritme toegepast worden op diverse soorten draadloze netwerktechnologie en radiofrequenties, waaronder lte en wifi. Het zou zelfs mogelijk zijn om netwerkapparaten gelijktijdig met deze netwerken te laten communiceren.

Bij praktijktesten zouden snelheidswinsten met een factor tien of meer zijn behaald, zo schrijft Technology Review. Op het wifi-netwerk van MIT zou de packet loss gemiddeld 2 procent bedragen. Door coded tcp toe te passen, zagen de onderzoekers de gemiddelde snelheid stijgen van 1Mbps naar 16Mbps. In een rijdende trein zou op een lte-verbinding met een packet loss van 5 procent een winst zijn geboekt van 0,5Mbps naar 13,5Mbps. Bij een scenario waar vrijwel geen packet loss is te bespeuren, is de snelheidswinst nihil, maar volgens de onderzoekers komt een verliesloze ip-verbinding bij draadloze netwerktechnologie vrijwel nooit voor.

Het coded tcp-protocol wordt inmiddels via licenties commercieel aangeboden via de start-up Code On. Enkele niet nader genoemde bedrijven zouden reeds een licentie hebben afgenomen, maar het is nog onduidelijk wanneer de eerste apparaten en netwerken met het protocol gaan werken. Volgens deskundigen is het niet ondenkbaar dat coded tcp over twee tot drie jaar breed zal worden toegepast door providers.

Reacties (128)

[Verwijderd]

Is dit echt iets nieuws? Voor satteliet communicatie wordt bijv. al reed solomon error correction toegepast. Het geflopte WiMAX gebruikte ook al iets dergelijks.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:07]

[scottbiker]

Inderdaad, niets nieuws: FEC noemt met dat (forward error correction: correctie gegevens die je doorstuurt om retransmissie overbodig te maken).

http://en.wikipedia.org/wiki/Forward_error_correction

[Reactie gewijzigd door scottbiker op 23 juli 2024 22:07]

[totaalgeenhard]

CRC voor TCP.

Enige wat ik niet begrijp is dat er commercieële licenties voor zijn, immers zo bijzonder is het niet.

[CodeCaster]

CRC voor TCP.

Met CRC kun je alleen controleren of het pakket is ontvangen zoals het gestuurd is, dit lijkt meer op ECC.

TCP werkt met een window, een waarde die bepaalt hoeveel pakketjes er "in flight" mogen zijn. Dit zijn pakketjes die onderweg zijn van verzender naar ontvanger, dus die nog niet definitief zijn aangekomen wat de zender betreft. Een TCP-window begint na het tot stand komen van de verbinding met een klein window en dus een slow start, omdat eerst moet worden bepaald hoe snel het netwerk de pakketjes kan verzenden. Hoe sneller dit gaat, hoe groter het window groeit en hoe meer data er dus tegelijk "op de lijn" gezet kan worden. Het window heeft ook een limiet, waardoor in sommige gevallen de beschikbare bandbreedte juist niet optimaal wordt benut.

Als nu bij klassiek TCP één pakketje uit een window wegvalt, moeten alle daarna ontvangen pakketjes door de ontvanger worden weggegooid en moet het ontvangen vanaf het gemiste pakket hervat worden met een gehalveerd window. Nog erger is het wanneer er te kort op elkaar te veel pakketjes wegwaaien, want dan treedt een timeout op door de vele out-of-sync acks, waardoor er even helemaal geen pakketjes worden uitgewisseld en het window weer minimaal is. Dit komt doordat TCP niet goed omgaat met random packet loss, omdat het voor bedrade netwerken is ontwikkeld. Bij een bedraad netwerk betekenen willekeurig verloren pakketjes meestal dat het druk is op het netwerk, dus door het window te verkleinen wordt aan congestion control gedaan, waardoor iedereen de beschikbare bandbreedte deelt. Bij wireless is de bandbreedte vaak niet het probleem.

Wat ik uit het paper haal: TCP/NC maakt gebruik van redundantie, door meerdere pakketjes aan elkaar te knopen. Hierbij maakt de volgorde van ontvangen niet meer uit, omdat het protocol aanneemt dat de overige pakketjes binnen het window nog wel zullen binnenkomen. Door deze werkwijze kan het window langer open blijven wanneer incidentele pakketjes wegvallen.

Het "klapperen" van het window is bij klassiek TCP desastreus, zeker bij draadloze verbindingen omdat packet loss daarbij nu eenmaal niet is te voorkomen in alledaagse situaties, en dat wordt met TCP/NC dus zo veel mogelijk voorkomen.

[Reactie gewijzigd door CodeCaster op 23 juli 2024 22:07]

[AmonTobin]

Ik heb eigenlijk nooit gesnapt waarom na packetloss de window size meteen weer terug moet springen naar miminaal. Waarom niet gewoon stapsgewijs afbouwen (zoals het ook opgebouwd wordt)? Bijvoorbeeld telkens halveren tot het weer goed gaat en dan de window size weer opbouwen. Of wellicht eerst 2 keer halveren en als het dan nog niet goed gaat, vanaf minimale window size weer beginnen.

Maar goed, er zal vast wel een reden zijn geweest dat ze dat niet hebben gedaan. Maar die reden ontgaat mij even.

[Verwijderd]

De window-size gaat niet direct terug naar minimaal.
Als ik me het goed herinner, wordt de window-size gehalveerd. Precies zoals je voorstelt.

Het idee van TCP is dat je de hoeveelheid brandbreedte die je gebruikt langzaam opvoert, totdat je drops ziet. Dan ga je half zo snel. En daarna voer je weer langzaam de snelheid op. Door zo sneller en langzamer te gaan, moet je het optimale punt bereiken waar je alle bandbreedte gebruikt, zonder er overheen te gaan. (In de praktijk zul je altijd een beetje blijven oscilleren, dacht ik me te herinneren).

Als je helemaal terug naar af zou gaan na iedere drop, dan kom je nooit bij je optimale punt.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:07]

[CodeCaster]

Niet na ieder pakketje nee, bedankt. Zie edit.

[AmonTobin]

Ah, ok. Ik heb toch altijd van meerdere bronnen begrepen dat dat wel zo ging (terug naar minimal). Maar zoals jij dat uitlegt is het idd ook wel logisch om het op die manier te doen om zo het optimale punt te bereiken.

Dank voor de info!

[Reactie gewijzigd door AmonTobin op 23 juli 2024 22:07]

[cdwave]

TCP heeft nu de neiging om constant net iets te hoog te gaan zitten. Daar komt dat oscileren vandaan. Ook daar zijn papers aan gewijd hoe je dit kan voorkomen, met veelbelovende resultaten, maar in de praktijk is er niks van terecht gekomen.

[nickelz]

Het is inderdaad de helft, terug naar minimaal zou echt niet gaan werken...

[froggie]

Deze keuze is gemaakt toen TCP met name over dedicated WAN verbindingen gebruikt werd, de bandbreedte van verbindingen een stuk lager lag en packet loss een minder groot probleem was door diepe buffers op tussenliggende hops. Om verschillende redenen komen we terug op deze beslissing wat bijvoorbeeld resulteert in Data Center TCP.

[AlterEgo]

Het is eerder par2 voor TCP

[Gehakt]

Dit is ook het eerste wat bij mij opkwam.

[Verwijderd]

Het is geen par2.
En het is geen error recovery.
Als je het paper leest, dan zie je dat het alleen over retransmissions, windowsize, acks en dergelijke gaat. Niks over error recovery. Imnsho slaat dat Technology Review artikel dan ook de plank 100% mis. "... promises to boost bandwidth tenfold". Onzin, bandbreedte blijft hetzelfde. Alleen de throughput gaat omhoog. Als je 10 gebruikers op een WLAN hebt, en je WLAN zit vol, dan gaat niemand meer bandbreedte, noch throughput zien.


In TCP worden acks gebruikt om retransmissions te vragen, als de ontvangende kant denkt dat hij data heeft gemist. (Impliciet, niet expliciet). Echter, drops zijn ook een mechanism van het netwerk om aan te geven dat je over je bandbreedte bent heen gegaan. En dat je dus iets langzamer moet gaan zenden.

Het probleem is dat deze twee functies in TCP tegelijk en door elkaar gebruikt worden.
1) Packetjes droppen omdat er iets mis ging met de transmissie ergens.
2) Packetjes droppen als indicatie dat je langzamer moet zenden.

Je kunt je voorstellen dat als er veel pakketjes worden gedropt omdat er ergens iets mis gaat met de transmissie (in je WLAN bv), dan kunnen computers niet zien of het nu echte drops waren, of dat het indicaties waren om langzamer te zenden. Op het moment zullen TCP implementaties dan ook gewoon langzamer gaan zenden. En je zult dan nooit maximaal gebruikt maken van de beschikbare bandbreedte.

Dit is wat dit algoritme probeert te verbeteren.

Zoals ik het begrijp, stuurt de ontvanger extra informatie terug in zijn acks, zodat de zender kan zien of er een of meerdere pakketjes gedropt zijn. En de zender gaat niet direct langzamer zenden, maar proberen om de snelheid er in te houden.


De key van het hele verhaal zit in deze paragraph van het paper:

There are several variants to the traditional TCP congestion control. For example, STCP [20] modifies the congestion control mechanism for networks with high bandwidth-delay products. Other variants include those with selec-
tive acknowledgment schemes [21]. It may be interesting to compare the performance of the TCP variants with that of TCP/NC. However, we focus on traditional TCP here.

Ze vergelijken hun oplossing met standaard ouderwetse TCP.
Echter, TCP heeft heel veel verbeteringen gekregen.
Bij voorbeeld "selective ack" (SACK).
http://en.wikipedia.org/w...Selective_acknowledgments

The use of SACK is widespread — all popular TCP stacks support it.

Zie rfc 2018: http://tools.ietf.org/html/rfc2018 Uit 1996.
En er wordt nog steeds gewerkt aan verbeteringen.
http://tools.ietf.org/html/rfc2883
http://tools.ietf.org/html/rfc3708

Deze developers hebben dus iets gemaakt dat helpt problemen voorkomen in technologie die al meer dan 10 jaar niet meer gebruikt wordt. Bravo. Hun hele "10x zo snel" argument is dus niks waard. Laat eerst maar eens zien hoe je verbetering zich verhoudt tot moderne technologie. TCP en SACK zijn open protocollen. SACK is een extensie die er op gericht is hetzelfde probleem op te lossen als dit paper. Deze TCPNC extensie is proprietary en houdt geen rekening met het feit dat SACK al een bestaande en gebruikte techniek is. Ik zie op het eerste gezicht weinig heil in TCPNC.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:07]

[mhkool]

Als je kijkt naar de error correction code van van antieke modems kijkt, snap je meteen dat het error correction is: een deel dat weggevallen is wordt opnieuw geconstrueerd met de codes van de andere delen. Het is dus wel degelijk error correctie.

Aangezien er prior art voor error correction code is, zal er geen patent op kunnen rusten. Een licentie voor dit algoritme? Alsjeblieft niet zeg!

[MSalters]

Ho ho, je kunt geen patent hebben op Error Correction. Dat is namelijk het doel. Er zijn een heleboel middelen om Error Correction te bereiken, en die specifieke middelen zijn individueel wel patenteerbaar.

[dasiro]

(binary) soduko

[alex3305]

Er zit al CRC in TCP, dus wat je nu zegt klopt niet. Wat de onderzoekers namelijk hebben gedaan is het combineren van pakketten in plaats van losse pakketten te sturen. Door verschillende wiskundige vergelijkingen toe te passen is daarnaast op een andere manier de betrouwbaarheid ook omhoog gegaan.

[Xuavis]

Betekent dit dat gewacht wordt op X aantal TCP pakketten voordat deze verstuurd worden? Ik kan me voorstellen dat bij applicaties waar een lage latency gewenst is (zoals games en beurssystemen) dit niet wenselijk is.

Als dit wel het geval is lijkt het me enkel nuttig dit protocol te gebruiken zodra packet loss optreedt.

[Verwijderd]

Ik kan me voorstellen dat bij applicaties waar een lage latency gewenst is (zoals games en beurssystemen) dit niet wenselijk is.

Als lage latency belangrijker is dan een verloren pakketje (bijvoorbeeld voip), dan gebruik je sowieso geen tcp maar udp.

[kibje]

Ik kan me eigenlijk niet voorstellen dat men dit gaat implementeren bij bedrade netwerkkaarten, waarover mensen vaak gamen. Wil je gamen over draadloze netwerken dan is het een ander verhaal:

Het betekent dat je doorvoersnelheid wellicht een procentje minder wordt maar dat de verbinding wel stabiel blijft als er storingen zijn in het netwerk waardoor pakketten verloren gaan. Dit is iets wat juist in draadloze netwerken (wifi, LTE, HSDPA, etc) regelmatig voorkomt.

Vallen er geen pakketjes weg dan heb je dus alleen iets langzamere throughput, aangezien er dan geen berekeningen hoeven te worden gedaan zal dit geen noemenswaardige invloed op de latency hebben.

Met andere woorden: Je kunt over wifi beter gamen, want alhoewel je latency misschien een procentpuntje slechter wordt, raak je ook veel minder snel de verbinding met het netwerk kwijt. Liever een constante latency van 21ms in plaats van 20ms dan dat je de hele tijd 20ms latency hebt, en elke 5 minuten een enorme lagspike waarbij je de verbinding kwijtraakt. (Rijdende trein scenario).

[Reactie gewijzigd door kibje op 23 juli 2024 22:07]

[Dlocks]

Op het wifi-netwerk van MIT zou de packet loss gemiddeld 2 procent bedragen. Door coded tcp toe te passen, zagen de onderzoekers de gemiddelde snelheid stijgen van 1Mbps naar 16Mbps.

Als ze op het WIFI netwerk van MIT normaal gesproken slechts 1Mbps halen zou ik eerst eens onderzoeken of er geen andere problemen zijn.

En bij packetloss van 2% dankzij coded ctp toe te passen snelheid met factor 16 verhogen? Weten ze zeker dat ze ook niet nog wat andere zaken hebben aangepast om het WIFI netwerk normaal te laten functioneren?

[DitisKees]

Zoals gryz in deze reactie mooi uitlegd zorgt packetloss voor een lagere zendsnelheid. Ook moet er vaak een veelvoud aan verloren pakketjes opnieuw verzonden worden. Gecombineerd kan dit dus ervoor zorgen dat de snelheid veel lager ligt dan theoretisch mogelijk.

[Dlocks]

Ja, dat had ik begrepen, maar als ik in den beginne op mijn WIFI-netwerk (of op werk) slecht 1Mbps behaal zoals bij MIT dan heb ik sterk het vermoeden dat er sowieso al iets mis is.

Dus je zou bijna denken dat bij de eerste meting (zonder toepassen coded tcp) er bij MIT al (tijdelijk) problemen waren met hun WIFI netwerk.

Alhoewel ik mag hopen dat een dergelijke fout bij MIT niet gemaakt wordt.

Desondanks wel vreemd dat het in testresultaat om factor 16 ging terwijl eerder in het artikel staat dat factor 10 mogelijk is. Dat is een gigantisch groot verchil:

Wetenschappers aan diverse universiteiten zeggen dat met behulp van een wiskundig algoritme de beschikbare bandbreedte op lte- en wifi-netwerken met een factor tien vergroot kan worden.

[..]

Door coded tcp toe te passen, zagen de onderzoekers de gemiddelde snelheid stijgen van 1Mbps naar 16Mbps.

[Reactie gewijzigd door Dlocks op 23 juli 2024 22:07]

[citegrene]

Ik kan met niet voorstellen dat bij een 5% packet loss een vertienvoudig van snelheid kan plaatstvinden zonder dat het ten koste gaat van iets anders.

[Reactie gewijzigd door citegrene op 23 juli 2024 22:07]

[borft]

eens, als er een packet loss is van 5%, betekent het lijkt mij dan 95% van je packets aan komen, zonder retransmits lijkt me dan, dus je benut dan 95% van je bandbreedte, hoe kan je dan ooit een verbetering halen die meer is dan je verlies?

[MadEgg]

Omdat, zoals CodeCaster hierboven uitlegt, alle packets die ná het foutief ontvangen packet verzonden zijn met de huidige protocollen óók opnieuw gestuurd worden.

Dat betekent dus dat als er 100 pakketjes verstuurd zijn (binnen het tcp window dus), waarvan 1-45 en 51-100 goed aankomen maar 46 t/m 50 niet goed, dan betekent dat dus dat niet alleen 46t/m50 overnieuw gestuurd worden maar dat 46 t/m 100 opnieuw verstuurd moet worden.

Met deze nieuwe methodiek lijkt het er dus op dat er géén packets opnieuw verstuurd moeten worden mits de wel goed overgekomen packets voldoende zijn om de vergelijking op te lossen. Is dat niet zo dan neem ik aan dat adaptief extra packets opnieuw gestuurd worden tot dat wel mogelijk is. Zo kun je behoorlijke snelheidswinst boeken.

[citegrene]

Dus als ik alles bij voorbaat al 2 x verstuur dan zou ik meer snelheid hebben dan het huidige tcp protocol?

[MadEgg]

Dat nou ook weer niet. Ik weet de exacte getallen niet, daar moet je wat statistiek en kansrekening tegenaan gooien. Heel ruw en kort docht de bocht volstaat het in 50% van de gevallen om alleen de tweede helft opnieuw te sturen, een kwart van de gevallen om slechts een kwart opnieuw te sturen etc. Uiteindelijk is het adaptief opnieuw sturen dan waarschijnlijk in de meeste gevallen sneller.

Bij hele slechte verbindingen zou jouw voorstel echter waarschijnlijk sneller zijn ja.

[Me_Giant]

Als je een pakket mist, moet je hem toch alsnog ophalen? Dat verdubbelt de wachttijd en dan heb je effectief de halve bandbreedte als ik het goed heb.

Als je met vier mensen van het vliegveld haalt en als je thuis komt blijk je met z'n drieën te zijn, moet je de vierde helemaal ophalen. Duurt dan dus 2x zo lang als gepland.

[xboxlivejunk]

Gaat het ook niet. Er is iets meer processor kracht nodig, maar niet veel. Kan me wel voorstellen dat de ping met deze methode omhoog gaat als je zo'n verglijking moet opzetten en weer uitvoeren bij verlies. Aan de andere kant zal een pakettje opnieuw versturen ook een vertraging opleveren.

[Verwijderd]

Fantastisch! Eindelijk hd films kijken via WiFI. Tot nu toe ben ik steeds teruggevallen op bedraad netwerk omdat WiFi niet stabiel genoeg bleek.

[Cheap Apps]

HD films heb ik totaal geen problemen mee om eerlijk te zijn. Waar ik vooral last van heb is een heel af en toe storend en wegvallend signaal. En er staat hier 2 routertjes in huis, en het gebeurt bij beide (bij de ene weliswaar meer dan de ander). Ik haal met gemak een snelheid van 120Mb/s, hoe veel meer heb je nodig voor een HD film?

[BugBoy]

Ik woon in een appartement en zie 15 netwerken. Mijn netto throughput over WIFI is 25-35mbit/s. Een beetje HD film loopt dan toch regelmatig te bufferen. Doe mij maar bedraad. Stabieler, minder latency en een stuk sneller.

[Cheap Apps]

Ik ben ook liever bedraad, en ik ben blij dat m'n desktopje weer aan het internet-infuus ligt, want ondanks dat de wifi vrijwel nooit weg valt, is die enkele keer toch wel vervelend.
Overigens heb ik van de pakweg 10 netwerken hier niet bepaald last. Waar ik standaard bij het instellen even naar kijk is welke kanalen vrij/rustig zijn. Als je zo'n 15 netwerken in de buurt hebt is het ook een tip om het rustigste kanaal te zoeken voor het beste ontvangst.

[joco]

het probleem is dat als je over 2.4GHz praat (5ghz is nog vrij onbemand meestal)
je maar 3 echte gebieden hebt 1, 6 en 11
en dan moet je geen paar hebben van die 15 die ook nog de 40mhz mode hebben ingeschakeld want daar passen denk ik nog geen 2 van op de 2.5Ghz band..
(een wifi ingesteld op 1 pakt 1-3 op 20mhz window en 1-7 in 40mhz

[ThePendulum]

Apart. Wij hebben beneden een media center staan die over wifi Full-HD films van een NAS haalt, en die films draaien behoorlijk soepel. Is er geen mogelijkheid om iets van pre-caching aan te zetten om het probleem te verhelpen?

[arjankoole]

Apart. Wij hebben beneden een media center staan die over wifi Full-HD films van een NAS haalt, en die films draaien behoorlijk soepel. Is er geen mogelijkheid om iets van pre-caching aan te zetten om het probleem te verhelpen?

Ik heb er maar gigabit ethernet voor aangelegd in huis. (Met relatief zware HP procurve switches) het betonijzer hier in huis stoort te veel om Full-HD te kunnen streamen over WiFi.

Het is maar precies hoe je huis in elkaar zit, hoeveel netwerken er zijn in de buurt, en nog 10 factoren.

[Buggle]

Dan raad ik je aan eens met inSSIDer te kijken welke kanalen er in je buurt nog redelijk vrij zijn, en die op je access point in te stellen. HD moet in principe gewoon mogelijk zijn over WiFi.

[thomasv]

Nou, ik heb ervaring met een klant in een flat waarbij er meer dan 20 storende kanalen zijn (allemaal verspreid) en het signaal dus sterk onderdrukt word op nog geen 10 meter van de bron. Signalen in je de buurt kunnen zeer vervelende stoorzenders zijn en HD streamen is daarom ook echt geen optie bij die klant.

* Uiteraard de buurt gecontroleerd via INSSIDer *

[The Reeferman]

inSSIDer leert mij dat er 63 netwerken zijn die storen als ik check vanuit mijn bed. Ik haal meestal ook niet hoger als 16Mbit meestal lager. Matige woonvorm die flats.

[tago673]

koop een Boxee Box zou ik zeggen, dan kun je bluray bestanden in 1080P zonder haperingen bekijken..

[Verwijderd]

Of je via wifi HD kan streamen hangt van heel veel factoren af, niet in de minste plaats de overige aanwezigheid van wifi gebruik in de omgeving. Ik ben er geen fan van.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:07]

[Keypunchie]

De vraag die ik heb met dit protocol: hoe makkelijk is het te implementeren in combinatie met al bestaande andere protocollen?

Het is een protocol voor de transportlaag, maar heeft het echt geen gevolgen voor de protocollen van de applicatielaag? Vooral voor streaming toepassingen kan ik me voorstellen dat het juist niet handig is om pakketjes te "bundelen", daar wil je zo veel mogelijk pakketjes in de volgorde waarin ze verstuurd worden.

Voor grote file-transfers is het daarentegen wel weer handig. Dat is niet zo tijdskritisch en volgorde kun je ook later weer rechttrekken. (bij streams zie je dat vaak dan toch ook weer "gebufferd" wordt, maar hierdoor krijg je een vertraging in je stream. Juicht iedereen bij een doelpunt van een voetbalstream weer op een ander moment dan de buren).

Zou het mogelijk zijn om afhankelijk van de applicatie de juiste variant van het algorithme in te zetten?

En ook: jammer dat het proprietary is en commerciele licenties nodig heeft. Dat gaat er praktisch altijd voor zorgen dat iets niet makkelijk breed word opgepakt.

[Terracotta]

Het TCP/IP model is zo opgericht dat een laag informatie krijgt van een lagere laag en dit doorstuurt naar een hogere opdat je dan één van de lagen apart kan wisselen indien er een betere methode gevonden wordt voor wat die laag doet. Dit zorgt ervoor dat dit nieuw protocol vrij eenvoudig toegevoegd kan worden zonder dat de andere lagen er last van hebben.

Bij streaming wordt zelden tcp gebruikt, juist omdat daar pakketten verliezen niet zo erg is, daar kan deze coded TCP misschien UDP vervangen (connectionless protocol, maar als het connection oriented protocol even snel is en minder of evenveel verlies oplevert dan kies ik toch voor de connection oriented versie).

Bij grote files heb je liever dat alles 100% overkomt, en in die situatie is de winst nihil, daar zal gewone TCP dus ook voor blijven gebruikt worden.

[Reactie gewijzigd door Terracotta op 23 juli 2024 22:07]

[koelpasta]

Je haalt dingen door de war. Je hebt het eigenlijk over het OSI model. TCP/IP implementeert delen van dat model.
Het OSI model is bedacht zoals jij dat zegt.
Maar OSI is geen implementatie maar slechts een abstractie.
Daar kun je eenvoudig de functionele lagen uitwisselen.

TCP/IP beslaat ongeveer 1.5 lagen van dat OSI model en is intern enorm verstrengelt.
Je kan niet eenvoudig het IP deel loshalen van TCP.
Vandaar dat in de praktijk over TCP/IP wordt gesproken en niet over de TCP/UDP protocollen en de IP protocollen.

[Jeoh]

Voor streaming zou je toch liever UDP gebruiken?

[Pomp]

Probleem zal niet de applicatielaag zijn, daar deze ongevoelig is voor de wijze waarop de data wordt verstuurd. Een applicatie geeft aan het onderliggende os door hoe deze zijn data wil versturen(ip/poort en transportprotocol). Het is dan aan het os om de datastroom afkomstig van de applicatie, doormiddel van zijn ip/tcp stack te vertalen, naar een netwerkstroom.

Waar het lastig wordt is de ondersteuning voor dit protocol. Dit moet op alle netwerkapparatuur die gebruikt worden voor LTE- en de verschillende mobieltjes worden geimplementeerd. Zo'n netwerk 'device' ', zal voor beide kanten die hij bedient(mobiel verkeer/achterlandschap) het verkeer beeindigen, vertalen om vervolgens deze weer op te bouwen richting de andere kant uit.

Om nog terug te komen op gestreamde data, zoals video, daar wordt vanwege het karakter van de data in principe gekozen voor UDP. Wat een seek en forget missle is. Daar is deze vinding niet op van toepassing.

[GlowMouse]

Bij wifi heb je een paar problemen. Een ervan is interferentie waardoor de data rate lager wordt. Coded tcp hier lost een ander probleem op, namelijk het reconstrueren van het oorspronkelijke bericht aan de hand van de pakketjes die goed aankomen. Momenteel bij TCP verbindingen (gebruikt bij websites opvragen en e-mail controleren) wordt een pakketje gewoon helemaal opnieuw verzonden. Daardoor gaat er veel bandbreedte verloren.

Voor implementatie hiervan moet zowel de applicatie als de server de taal van coded tcp spreken. Dat zorgt voor een langzaam overgangstraject. De enige manier om dit te voorkomen is door gebruik te maken van tunneling. Wat je nu vaak ziet is dat een internetverbinding weel langzamer wordt door zo'n tunnel (vaak in de vorm van een VPN aangeboden), omdat de tunnelprovider over onvoldoende bandbreedte en rekenkracht beschikt.

[arjankoole]

Voor implementatie hiervan moet zowel de applicatie als de server de taal van coded tcp spreken.

Jij zit alweer veel te hoog in de netwerk stack. Als wireless accespoint en wireless netwerkkaart / chip in de computer / tablet / smartphone het ondersteunen ben je er al. Voor LTE moet de cel/mast het ondersteunen, en de 4G chip in je apperaat. (Tablet, telefoon, dongle)

Dat maakt het al een stuk eenvoudiger. :-)

[GlowMouse]

Het klopt niet wat je zegt, in het artikel staat duidelijk dat het decoden pas bij de ontvanger gebeurt:

Here, we focus on TCP/NC with end-to-end network coding

Ik ben het wel met je eens dat je bestaand TCP verkeer eenvoudig kunt tunnelen met behulp van wat extra software in het access point (maar die moet wel heel vlot een stelsel lineaire vergelijkingen kunnen oplossen).

[arjankoole]

Dan klopt wat ik zeg nog steeds. Beide kanten zijn zowel zender als ontvanger, en aan beide kanten los je dit op voor het de applicatielaag raakt. Liefst zelfs in hardware, maat in software is een goedkopere oplossing. (En snel qua implementeren)

Dus beide kanten coderen het verkeer met dit algoritme, en beide kanten decoderen het ook weer voor het verder gestuurd wordt. Daarom zijn die dingen transceivers per slot van rekening.

[Jaco69]

Op IP nivo zijn de zender en ontvanger de 'client' en de 'server'.
Alles daar tussen is een doorgeefluik en werkt vaak een nivo lager. Ook de doorgeefluiken op IP nivo (de routers) zouden wel van alle connecties kunnen gaan bijhouden wat verzonden is en wat verloren is gegaan. Maar ze kunnen niet op de connectie gaan inbreken en voor re-transmits en dergelijke gaan zorgen.

[SpX]

Lijkt deze methode niet een beetje op quickpar's methode om bestanden die onvolledig zijn aan te vullen zodat ze toch hersteld en compleet worden gemaakt. In de par bestanden bevind zich de info aanwezig zou moeten zijn. Ik kan er ook helemaal naast zitten.

[Xorsist]

Indien dit zo zou zijn zouden er ook "par bestanden" meegestuurd moeten worden. Dit houdt direct in dat er meer bandbreedte verstookt gaat worden. Het lijkt mij niet dat deze kant op gewerkt gaat worden.

Gezien de datastromen welke tegenwoordig lopen lijkt mij dit een natuurlijke ontwikkeling van het meegeven van CRC voor 1 blok naar het meegeven van een CRC naar X blokken.

Dat dit dan direct in een commerciëel model gegoten moet gaan worden lijkt mij voor de mate van adoptie nou niet echt handig, maar goed wie ben ik. Dit soort ontwikkelingen welke een ieder ten goede komen en waardoor de efficiency van de user experience vooruit gaat zou m.i. onder een open source licentie thuis horen om acceptatie en integratie op een zo snel mogelijke manier plaats te laten vinden.

[OddesE]

Doe dat dan? Je kunt een Open Source project starten binnen een uur.

Punt is natuurlijk dat er jaren werk achter zit en dat men graag een poging wil wagen daar ook wat aan te verdienen. Het valt mij op de mensen altijd zo makkelijk het geld of de tijd van andere mensen weggeven. Heb jij al een project online staan dat we kunnen downloaden? Hoeft niet per se een TCP protocol te zijn, maar gewoon überhaupt iets?

[hardwareaddict]

Als ik hoor 'universiteiten hebben in tijd van de baas iets ontwikkeld' en dan lees ik in de commentaren zo iets van 'licentiekosten'.

Dan denk ik: dit gaat er NOOIT KOMEN, TENZIJ ze het gratis weggeven.

[Nactive]

Het einde van het artikel is zo jammer. Het wordt vanuit de universiteiten onderzocht maar toch is het nog een commercieel product waar een licentie (die waarschijnlijk veel geld zal kosten) aan vast hangt.

Voor de rest een zeer interessant artikel al kan het wel interessant zijn om gewoon te spreken over foutcorrectie in het artikel in plaats van het zo vaag te omschrijven .

[ATS]

Met een mooi woord heet dat valorisatie hier in Nederland, en het wordt enorm gestimuleerd door de overheid. Als je als universiteit je vindingen niet te gelde maakt, dan doe je het niet goed en dat kost financiering.

Universiteiten zitten al vele jaren in de hoek waar de financiële klappen vallen. Het te gelde maken van je uitvindingen is één manier voor universiteiten om hun inkomsten op peil te houden.

[mae-t.net]

Bovendien kom je zo sneller aan klanten. Van het budget dat je binnenhaalt met de licentieverlening kan je actief vertegenwoordigers naar potentieele klanten sturen. Iets waar universiteiten uitzichzelf toch nooit zo veel aan deden.

[hardwareaddict]

@nactive, dit is compleet oninteressant als ervoor betaald moet worden natuurlijk - als je namelijk licentiekosten gaat betalen voor dit dan ken ik nog wel paar miljoen verbeteringen die je door middel van geld te betalen voor elkaar krijgt

[mae-t.net]

Noem er eens een paar? Ze moeten wel een even goede of betere prijs/kwaliteitsverhouding hebben.