Aspera claimt datasnelheden iPhone te kunnen verdriedubbelen

Aspera, een bedrijf dat zich gespecialiseerd heeft in datatransmissie, denkt met de fasp-AIR-technologie de doorvoersnelheid via iPhones over 3g-netwerken en wifi te kunnen verdrievoudigen. De techniek is gebaseerd op een nieuw protocol.

Aspera heeft het zogenaamde fasp-protocol ontwikkeld waarmee, zo claimt het bedrijf, data op hogere snelheid kan worden verzonden dan bij gebruik van tcp. Fasp wordt al door diverse grote organisaties gebruikt; nieuwszender CNN gebruikte het bijvoorbeeld om beelden van de aardbeving in Haïti snel naar de thuisbasis te sturen. Naast zakelijke en wetenschappelijke toepassingen wil Aspera zijn protocol nu ook voor de iPhone beschikbaar maken.

De naam fasp staat voor 'fast and secure protocol'. Volgens Aspera-directeur Michelle Munson wordt de hogere snelheid onder meer behaald door het versturen van grotere datapackets dan bij tcp. Verder zullen pakketjes alleen opnieuw verstuurd worden als wordt bevestigd dat ze onderweg verloren zijn gegaan. Bij tcp is het noodzakelijk dat de ontvanger een ontvangstbevestiging terugstuurt, anders zal het packet opnieuw verzonden worden. Hierdoor is tcp voornamelijk handig wanneer de data-overdracht precisie vereist.

De fasp-variant voor de Apple iPhone draagt de naam fasp-AIR en zal tijdens de Macworld-conferentie in San Francisco geïntroduceerd worden. Vervolgens zal er een applicatie verschijnen die iPhone-gebruikers in staat zou moeten stellen om de snelheden over hun 3g- en wifi-connecties te verdrievoudigen. Ook verschijnt er een sdk, waarmee ontwikkelaars het protocol in hun eigen apps kunnen verwerken. Met name applicaties die baat hebben bij hogere upstreamsnelheden, zouden van het fasp-AIR-protocol kunnen profiteren. De software zou binnen een half jaar moeten verschijnen.

Reacties (63)

[Verwijderd]

Volgens Aspera-directeur Michelle Munson wordt de hogere snelheid onder meer behaald door het versturen van grotere datapackets dan bij het tcp-protocol.

Is dat handig? Dat betekent namelijk dat als een packet verminkt aankomt (of helemaal niet aankomt), je ook een groter packet *opnieuw* moet versturen. En aangezien de kans daarop bij draadloos mobiel gebruik een heel stuk groter is dan een wired netwerk, lijkt dit me niet handig als je in een intercity door een weiland zit.

Verder wordt er niet gewacht op een bevestiging alvorens een volgende packet verstuurd wordt

Wat TCP ook niet doet, dus ik zie het voordeel niet helemaal.

en zullen pakketjes alleen opnieuw verstuurd worden als wordt bevestigd dat ze onderweg verloren zijn gegaan.

Zoals bij TCP dus.

De term "drievoudige datasnelheid" vind ik op zich ook niet veelzeggend. De bandbreedte zou je kunnen verhogen, maar wat zijn de gevolgen voor de delay? Als je dit soort technologie voor videoconferencing gaat toepassen, wordt je wel blij van meer bandbreedte, maar niet als dat meer vertraging of jitter met zich meebrengt.

Ik heb moeite met geloven dat een commercieel bedrijf met een techniek komt, die beter zou moeten zijn dan een wereldwijd geaccepteerde IP-stack die al 20-30 jaar bestaat en dus redelijk uitontwikkeld is.

Sowieso ben ik huiverig voor proprietary technologieen in de netwerkstack.

@arjankoole: precies, *als* dat relatief weinig voorkomt. De kans dat dit voorkomt op een mobiele draadloze verbinding over enkele km's in de buitenwereld, is vele malen groter dan op een wired gigabit-netwerk...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:16]

[arjankoole]

Is dat handig? Dat betekent namelijk dat als een packet verminkt aankomt (of helemaal niet aankomt), je ook een groter packet *opnieuw* moet versturen.

Als dat relatief weinig voorkomt levert dat best wel grote winsten op denk ik zo.

Denk aan jumbo-frames op NIC's die GigE doen of hoger. Daar is het principe al veel langer in gebruik. Deze club toen gewoon iets speciaals voor content-distributie. ( een club als CNN is ook niet achterlijk, blijkbaar bespaart dit voor hun sateliet tijd, wat best duur is)

[depeje]

Ik weet niet of de CNN die beelden ook live gebruikte, maar als dat niet zo is, maken jitter en delay ook echt niets uit. Dan draait het enkel om een zo laag mogelijke overhead.

[arjankoole]

Ik weet niet of de CNN die beelden ook live gebruikte, maar als dat niet zo is, maken jitter en delay ook echt niets uit. Dan draait het enkel om een zo laag mogelijke overhead.

Ook bij niet live maakt het uit. Iedere seconden die je minder aan sateliet tijd moet betalen levert al een leuke besparing op. Als je dat extrapoleert op de enorme hoeveelheid blokjes sateliet tijd die een zender als CNN gebruikt, kan dat een enorme besparing opleveren. De overhead is inderdaad ook van belang, omdat je minder bandbreedte overhebt ( tot 16% in het geval TCP) voor de daadwerkelijke nuttige payload.

Tel beide factoren bij elkaar op, en je komt heel, heel ver denk ik zo.

[FlorisB]

Is dit niet eigenlijk een soort versimpelde versie van de TCP-vervanger voor communicatie naar satellieten enzo?

Mooie ontwikkeling!

[bomberboy]

Het is helemaal geen TCP vervanger. Afgaande op de (beperkte) informatie op hun website is het trouwens een protocol op de applicatielaag (denk http, ftp etc) en niet op de transport laag (udp, tcp etc).

Het werkt ook gewoon bovenop de bestaande IP-netwerken. Met andere woorden het lijkt erop dat ze een FTP-achtig stuk software geschreven hebben (wss met communicatie op basis van UDP) waarbij ze zelf instaan voor de reliability, dus retransmit indien iets verloren gaat of aan de hand van extra bits verloren pakketjes reconstrueren (vgl met RAID).

"Speciaal" aan hun oplossing is dat ze blijkbaar een enorm groot window gebruiken vooraleer ze iets retransmitten (of extra bits toevoegen zodat ze verloren/kapotte pakketen kunnen reconstrueren) zodat de performance degradatie minimaal is op lossy links.
Niet echt iets spectaculairs dus...

Bovendien moet je applicatie dan specifiek herschreven worden om van dat ftp-achtige protocol gebruik te maken en moet er aan de andere kant een server staan die dat protocol ook spreekt.

Het heeft dus eigenlijk nauwelijks iets te maken met TCP en al helemaal niet met de iPhone...

[arjankoole]

Met andere woorden het lijkt erop dat ze een FTP-achtig stuk software geschreven hebben (wss met communicatie op basis van UDP)

Ik denk eerder dat ze een compleet nieuwe kruising tussen TCP en UDP hebben gebouwd. Puur UDP gebruiken zou niet werken, aangezien UDP een zeer beperkte packet grote heeft (512 zo snel uit m'n hoofd - iets waar je rekening mee moet houden in DNS zonefiles).

[bomberboy]

Ze zeggen zelf dat het een protocol op de applicatielaag is, dus is er aan de onderliggende lagen helemaal niets gewijzigd. Eventueel kunnen ze helemaal FTP overgenomen hebben en een controle connectie over TCP en de eigenlijke dataconnectie over UDP realiseren.

Maar dat houdt nog steeds in dat het voorgestelde applicatielaag protocol fasp-AIR protocol absoluut niet vergelijkbaar is met een transportprotocol als TCP. Check het OSI netwerk model: http://en.wikipedia.org/wiki/OSI_model

[seal74]

Het enige wat ik kan bedenken is dat ze de MTU (Maximum Transmission Unit) op de transportlaag (TCP) extra hoog forceren waardoor je op de transportlaag minder ACK en NACK berichten krijgt. Daarnaast hebben ze waarschijnlijk een eigen applicatie protocol bedacht die waarschijnlijk data blocken versturen die even groot of een veelvoud van de MTU zijn. Op die manier benut je de transportlaag voor de volle 100%. Daarnaast zullen ze de mogelijkheid hebben ingebouwd om meerdere kleinere bestanden of fragmenten daarvan in 1 bericht te stoppen.

Simpel gezegd: Ze zoeken de maximum lengte van een vrachtwagen op een bepaalde weg. Als ze die lengte hebben gevonden sturen ze alleen maar vrachtwagensmet die lengte op de weg die helemaal gevuld zijn.

[MSalters]

Waar heb je het over?

MTU (Maximum Transmission Unit) is een een eigenschap van een packet-oriented netwerk met variabele packet sizes, zoals IP. TCP is streambased, en kent dus geen MTU.

Bovendien is de MTU geen eigenschap die je kunt "forceren". Laat staan op andermans netwerk, waar de iPhone gebruik van moet maken.

[burne]

De maximale frame-lengte van een UDP-packet is 65,507 bytes. Op ethernet is je ethernet-MTU het probleem, niet die van UDP.

Het verhaal met DNS was een afweging tussen snelheid en betrouwbaarheid. Het idee was, destijds, dat eenvoudige antwoorden met UDP afgehandeld werden, en dat als je complexere dingen ging doen, zoals hele zone's opvragen, je daarvoor de extra betrouwbaarheid en automatische foutcorrectie van TCP wilde hebben. Dat is een keuze in BIND geweest, niet eentje die door het UDP-protocol opgelegd wordt.

[Verwijderd]

TCP is niet echt efficient, maar wel robuust.

Echter kunnen de voordelen van robuustheid ook bereikt worden door toevoeging van bijvoorbeeld hamming - code waardoor verloren data blokken toch hersteld kunnen worden.

Voor het streamen van video is TCP bijzonder ongeschikt.

Bijvoorbeeld UDP gebasseerde protocollen waarbij data verlies gecompenseerd of geaccepteerd worden bieden dan groot prestatie voordeel.

Als je een betrouwbaar switched netwerk hebt is TCP eigenlijk niet nodig voor de ontvangst controle.

Het nieuwe protocol dat hier gepresenteerd wordt zal misschien wel nadelen opleveren zoals netwerk congestie (te veel verkeer op een network lijn).

TCP zal i.v.m. backward compatibility van bestaande applicaties belangrijk blijven en zal eventueel gerbridged moeten worden. Ontvangst controle van de pakketten kan natuurlijk ge-faked worden in de TCP stack van de client indien het bridge protocol echt betrouwbaar is.

Flow control zal ook anders gereguleerd moeten worden.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:16]

[JackBol]

Als je een betrouwbaar switched netwerk hebt is TCP eigenlijk niet nodig voor de ontvangst controle.

Dat is natuurlijk niet waar. Zelfs de duurste ethernet switches zijn gevoelig voor microburst en microcongestion op output buffers.

Alleen met lossless ethernet (DCE) is het mogelijk om zonder TCP betrouwbaar gegevens over te sturen, omdat de reliability dan in Layer 2 word afgevangen.

[Verwijderd]

met een betrouwbaar switched network bedoel ik niet meteen automatisch een ethernet topologie. Ik dacht eigenlijk meer aan een netwerk vergelijkbaar met bijvoorbeeld ISDN, maar dan liefst sneller uiteraard. Bij ISDN bijvoorbeeld (circuit geschakeld ; snelheid bezwaren even terzijde) heb je altijd een gegarandeerde doorvoer van data stroom, een betrouwbare hoge kwaliteit en dus hoge zekerheid dat het pakket afgeleverd wordt.

Daarom wordt voor een kwalitatieve goede en betrouwbare audio verbinding naar een radiostation bijvoorbeeld ook vaak isdn-2 / 4 gebruikt.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:16]

[erikdeperik]

is dit niet ong hetzelfde als jumbo frames?

[ultimasnake]

Maar waarom zou dit beperkt moeten worden tot de iphone? Lijkt me juist een lastig platform door het gesloten beleid van apple... maar goed, proof of concept gok ik zo... En waar ligt de implementatie aan de andere kant? Zal de provider ook iets moeten doen of is het vooral serverside af te vangen? Aangezien het niet via TCP/IP gaat lijkt het me lastig direct over 3g te pushen of mis ik wat

[Verwijderd]

Ja, de iPhone zal straks 'n steeds ondergeschiktere rol spelen, na de hype. Android gaat 'n veel betere toekomst tegemoet & eerlijk gezegd vind ik dat momenteel ook 't beste platform voor Smartphones, dus laat fasp-AIR maar komen voor Android!

[Verwijderd]

Als een hype al 3 jaar duurt, is het dan wel een hype?

Daarnaast is de Android zeker niet het beste platform voor smartphones. Wat ik van developers hoor: van alle opensource platformen is Android nog steeds het meest gesloten, door allerlei regeltjes van Google. Het platform is niet zo opensource als Google de wereld wil doen geloven.

[blouweKip]

Het is minder gesloten dan de iphone en windows mobile (maar dat klinkt minder negatief natuurlijk)

[Tropical_Daddy]

Is Windows Mobile dan zo gesloten? Je kan dan de broncode niet inlezen, maa rik heb het idee dat de SDK van WinMo toch een stuk mee toe laat dan die van Android...

[Jaap-Jan]

Of het wordt ingebouwd in de Linux- kernel, dan hebben alle apparaten die Linux draaien gelijk ondersteuning daarvoor. Wel zijn er dan nog userland tools nodig om FASP te kunnen configureren. Maar FASP draait bovenop UDP/IP, dus veel configuratie zal er niet nodig zijn.

De tests die Aspera heeft uitgevoerd zijn gedaan op Debian Linux bakken, dus er is al een implementatie van FASP op Linux. Ik denk wel dat die in User Space zijn gedaan, door via FASP direct UDP datagrammen te versturen.

Het enige wat jammer is, is dat het een gesloten technologie is.

[Reactie gewijzigd door Jaap-Jan op 23 juli 2024 01:16]

[ZpAz]

Android gaat 'n veel betere toekomst tegemoet

Daarom gaan applicatie ontwikkelaars ook massaal over op Android... oww wacht, nee toch niet.

Vanaf het moment dat Android uit was hoor ik dat al, en ik heb er nog weinig van gemerkt, het heeft een redelijk marktaandeel, maar Apple gaat echt niet krimpen ten koste van Android, enkel wordt er vooral weggesnoept bij WinMo mocht Microsoft niet snel met iets beters op de proppen komen.

[Reactie gewijzigd door ZpAz op 23 juli 2024 01:16]

[To_Tall]

je kan het ook zien als een test platform. iPhone wordt door veel consumenten gebruikt, sinds de iPhone is het mobiel internet enorm gestegen.

Een mooier platform kan je dan denk ik niet wensen. Slaat het aan kan misschien door de tijd het TCP platform worden vervangen binnen overige systemen.

[Bacchusius]

Kun je dan ook niet gewoon UDP i.p.v. TCP gebruiken?

[Bob]

Ik denk dat ze het beste van de twee werelden willen, snel en betrouwbaar. Wanneer een programma een UDP verbinding maakt, moet het programma er voor zorgen dat er geen dataverlies optreedt wanneer een pakketje onderweg beschadigd of verloren geraakt. Kan soms handig zijn om dat door een programma te laten afhandelen, maar meestal is dat te veel extra werk voor de programmeurs, waardoor TCP (met al z'n voor- en nadelen) wordt gekozen.

[Grijze Vos]

Nee, wanneer een programma UDP gebruikt moet het niet uit maken als er een pakketje mist. Anders gebruik je dus TCP.

Dat is het hele idee van de layering van netwerkprotocollen, je handelt het juiste probleem op het juiste niveau af. Robuustheid van de connectie handel je dus af op de transport layer, waar TCP en UDP zich bevinden. Dit doe je niet in de applicatie layer.

[Bob]

Dan mis je toch iets hoor, vele games gebruiken UDP (oa quake 3 dacht ik) en die proberen data verlies echt wel op te vangen. Best effort + proberen zoveel mogelijk uit de binnenkomend data sleuren + evt requests om data als er toch iets essentieels ontbreekt.

[Sharkey1802]

Zo'n protocol kan toch op veel meer systemen werken dan alleen de IPhone?

Beetje vreemd dat ze dan voor de IPhone kiezen. Het lijkt mij makkelijker om bijvoorbeeld voor Maemo te kiezen want dat is veel opener.

[arjankoole]

Zo'n protocol kan toch op veel meer systemen werken dan alleen de IPhone?

Absoluut.

Beetje vreemd dat ze dan voor de IPhone kiezen. Het lijkt mij makkelijker om bijvoorbeeld voor Maemo te kiezen want dat is veel opener.

Misschien willen ze juist niet meer open, omdat hun spullen niet 'open' zijn, maar juist heel erg propietary.

[Bacchusius]

Anders brengt Google het toch uit op het Android platform?

[Ferdi Nando]

Mooie ontwikkeling, maar dit lijkt me meer iets voor de Windows Mobile telefoons.
Deze is toch iets meer voor de serieuze en zakelijke gebruikers. Die hebben denk ik het meeste baat bij een snellere verbinding, alhoewel youtube onderweg wel wat sneller zou kunnen.

[blouweKip]

Ik ken geen enkele zakelijke gebruiker met windows mobile op zn telefoon (je weet dat meuk zoals exchange inmiddels ook compatible is met de rest van de wereld?)

[vgroenewold]

Dit is iets voor gebruikers die veel Internet-verkeer genereren en laat dat nu net de gemiddelde iPhone gebruiker zijn. Alle platforms hebben hier natuurlijk uiteindelijk voordeel bij, maar de iPhone is een uitstekend platform om de boel op te testen. Overigens zie ik zakelijke gebruikers BlackBerries gebruiken.

[Reactie gewijzigd door vgroenewold op 23 juli 2024 01:16]

[tofus]

"An Open Internet Demands Open Standards"...'nuff said.

Ik moet er niet aan denken dat ik straks voor elk bitje dat ik verstuur/ontvang licentie-rechten moet afdragen aan Aspera, ongeacht de content die ik over hun protocol verzend.

Het internet is groot geworden door z'n openheid en de mogelijkheid voor iedereen om op basis van publiek beschikbare RFC's een TCP stack te bouwen om iets 'aan' internet te hangen.

Dit soort initiatieven, hoewel technisch wellicht intrigerend, is natuurlijk niks minder dan een commerciele poging het 'fundament' van informatie-overdracht te kapen en daarna onbeperkt uit te melken.

[Loadjnt]

Eerst zien dan geloven. Ik heb meer het idee dat dit bedrijf publiciteit probeert te creëren door de Iphone te noemen. Dit gaat volgens mij voor elke smart-phone werken. Het zal in iedergeval wel baanbrekend zijn...

[Bacchusius]

Aangezien Fasp-AIR in software draait, is het de vraag of de iPhone dit kan bijbenen...

[vgroenewold]

Waarom zou dat niet het geval zijn, ik denk niet dat dataverkeer nu zo'n probleem is aangezien ik via wifi thuis veel hogere snelheden haal.