Peerings beter dan transitverbindingen?

BvdHeide · #1 (**permalink**) 14 September 2009, 22:01

Wat ik altijd een beetje mysterieus vindt is dat het downloaden vanaf een AMS-IX peer altijd met volle snelheid verloopt terwijl bij een transitverbinding de snelheid continu wankelt. Ik heb het zelfde grapje ook bij Debian gedaan, een mirror gepakt die een peering op de ams-ix had wat resulteerde in een zeer vlotte en stabiele download in tegenstelling tot een transitverbinding die continu wankelt als ik de mirror vanaf Spanje download.

Nu vraag ik me toch af of dat normaal is, dat downloads buitenom een IX die via een transit verlopen altijd afgeknepen worden of onstabiel zijn? Stel als ik nou in Washington zit en wil een file vanaf een Nederlandse server downloaden, dan neem ik wel een dat dit via een transit verloopt en afgeknepen wordt. Kan een hostingprovider dit dan simpel oplossen door met een US IX te gaan peeren?

pvdpf · #2 (**permalink**) 14 September 2009, 22:07

Een peering is altijd "korter" als een Transit.
En vaak daarom sneller.

Dat je snelheid wankelt hangt van de kwaliteit van de transit provider af en alles wat daar tussen zit.

Apoc · #3 (**permalink**) 14 September 2009, 22:32

Wat pvdpf zegt klopt volledig, maar ik denk niet dat het daar aan ligt.

Bij peering is de traffic (normaliter) gratis. Als je een gigE peering verbinding hebt, maakt het geen verschil of je nu 10mbit of 600mbit verbruikt, de kosten zijn hetzelfde.

Bij transit betaal je per megabit, dus maakt het aanzienlijk verschil of er dus 10mbit of 600mbit gebruikt wordt.

Het kan dus zijn dat het verkeer wat over transit loopt, geknepen wordt. Of het zou simpelweg kunnen zijn dat er simpelweg een beperktere bandbreedte via transit beschikbaar is, en dat dus de volledige verbinding benut wordt (hetgeen ook de onstabiliteit zou verklaren).

Maar; je moet natuurlijk wel appels met appels vergelijken. Je kunt transit naar Spanje niet vergelijken met peering binnen NL. Daar zijn veel te veel variabelen voor.

Citaat:

Oorspronkelijk geplaatst door BvdHeide

Stel als ik nou in Washington zit en wil een file vanaf een Nederlandse server downloaden, dan neem ik wel een dat dit via een transit verloopt en afgeknepen wordt. Kan een hostingprovider dit dan simpel oplossen door met een US IX te gaan peeren?

Dit zal meestal idd via transit lopen, tenzij het via peering kan. Maar, transit wordt normaliter niet geknepen. De reden dat bandbreedte lager is voor lange afstanden, heeft een heel andere verklaring. Dit heeft te maken met hoe packets verzonden worden. Dit is een vrij lang en technisch verhaal, maar in het kort komt het min of meer hier op neer:

Wanneer een packet verzonden wordt, zal de volgende packet pas weer verzonden worden zodra de ontvanger de ontvangst van het vorige pakket heeft bevestigt. Dit betekent ook dat wanneer de latency hoger is, de hoeveelheid packets die in een bepaalde tijdsspanne verstuurd kan worden, kleiner wordt.

BvdHeide · #4 (**permalink**) 14 September 2009, 22:43

Bedankt voor je inputpvdpf en Apoc.

Wat betreft lange afstanden, hoe lossen hosters het snelheidsprobleem via transit door de lange afstand dan op? Een vriend van me had onlangs in China al zijn foto's en video's in een RAR gepompt, en via glasvezel aldaar naar hier willen sturen, ondanks dat we beiden op glasvezel zaten verliep de overdracht ontzettend langzaam. Hoe valt zoiets in de toekomst op te lossen?

pvdpf · #5 (**permalink**) 14 September 2009, 22:51

Tja.. via velen omwegen en providers kom je via hier naar China en v.v.

Wat je het beste kan doen lijkt mij is allebei kijken naar welk land de snelheid van jullie beide verbindingen het snelst is.
Daar space afnemen.
Hij upload - jij download.
Alle bij een snelle maar geen rechtstreekse verbinding.

Apoc · #6 (**permalink**) 14 September 2009, 23:07

Het feit dat jullie allebei op glasvezel zaten, zegt natuurlijk niet heel erg veel. Het gaat uiteindelijk enkel om de langzaamste verbinding die je onderweg tegenkomt (bottleneck), en dat zijn er tussen NL en China nogal wat.

Echter, daar zal het inderdaad niet echt aan gelegen hebben, maar voornamelijk aan de afstand. China is nog een stuk verder weg dan de VS (en dan doel ik niet enkel op de geografische afstand, maar ook de afstand over internet).

Het probleem ligt bij de technologie en zal dus uiteindelijk ook enkel via verbeterde technologie opgelost kunnen worden. Wat je wel zelf kunt doen, is de techniek bekijken die je zelf gebruikt. Verschillende protocollen hebben ook verschillende snelheden.

Apoc · #7 (**permalink**) 14 September 2009, 23:11

Citaat:

Oorspronkelijk geplaatst door pvdpf

Wat je het beste kan doen lijkt mij is allebei kijken naar welk land de snelheid van jullie beide verbindingen het snelst is.
Daar space afnemen.
Hij upload - jij download.
Alle bij een snelle maar geen rechtstreekse verbinding.

Zou kunnen, maar is wat omslachtig tenzij je het regelmatig nodig hebt. Het lijkt me dan logischer om meerdere packets simultaan te versturen. De hoeveelheid bandbreedte per stream is wellicht beperkt, maar je bent natuurlijk niet tot maar 1 stream beperkt.

BvdHeide · #8 (**permalink**) 14 September 2009, 23:45

Ik zou kunnen testen of het via FTP iets sneller gaat maar ik betwijfel het. Stel als mijn provider een peering zou hebben met China, zou dat dan het gehele probleem oplossen of blijft het simpelweg langzaam vanwege de lange (geografische) afstand?

Zelf dacht ik altijd dat de geografische afstand geen rol speelde maar blijkbaar ligt de beperkte bandbreedte daaraan icm met mogelijke knelpunten binnen de transit. Tevens is het na mijn mening zo dat binnen transits meer knelpunten zitten dan wanneer je direct met een IX zou gaan peeren. Dit omdat je bij een transit simpelweg met tig andere partijen op één netwerk zit met ieders zijn eigen bestemming.

Ook al zou mijn provider gaan peeren met China lost dat weinig op omdat de afstand dusdanig groot is dat snelle bestandsoverdracht onmogelijk is?

Natuurlijk ben ik nog steeds opzoek naar een oplossing, mocht ik ooit klanten krijgen in China wil ik natuurlijk wel dat alles vlot verloopt. Op dit moment nog geen technologische oplossing daarvoor?

MMaI · #9 (**permalink**) 15 September 2009, 00:27

gaaaaaap:
http://www.webhostingtalk.nl/dedicat...and-china.html (Snelle internet lijn opzetten Holland - China)

en nu ga ik slapen

Jefke · #10 (**permalink**) 15 September 2009, 06:02

De afstand heeft uiteraard invloed op de rtt (round trip time) en door de eigenschappen van TCP heeft de rtt rechtsteekse invloed op de maximum snelheid van een TCP sessie.

Even voor je gegoogled, en hier is dit bijvoorbeeld mooi uitgelegd:
http://blog.httpwatch.com/2008/08/14...ownload-speed/

UDP heeft daar op zich geen last van maar de toepassingen die van UDP gebruik maken zorgen vaak dat rtt ook daar een rol speelt.

The-BosS · #11 (**permalink**) 15 September 2009, 06:44

Citaat:

Oorspronkelijk geplaatst door BvdHeide

Tevens is het na mijn mening zo dat binnen transits meer knelpunten zitten dan wanneer je direct met een IX zou gaan peeren. Dit omdat je bij een transit simpelweg met tig andere partijen op één netwerk zit met ieders zijn eigen bestemming.

Dit verhaal klopt alleen als je eigen fibers tussen punt A & B liggen hebt, maar aangezien de meeste providers hier het geld niet voor hebben huren ze MPLS tunnels af bij transit providers. Hierdoor lijkt het op de traceroute dat het maar over 1 hop (router) gaat, maar in feite volgt de mpls tunnel de zelfde weg als de transit routing. Dit is juist hetzelfde als je met een vpn verbinding doet. Je zet een secure tunnel op van punt A naar B en lijkt het 1 hop maar gaat toch gewoon over je kabel/adsl/transit/etc.

Verder zijn meerdere hops over lange afstand niet altijd slechter, aangezien een router ook als repeater fungeerd wordt het packet weer versterkt in signaal en beter doorgezonden of kan er vlugger ingespeeld worden op lost packets. Vergelijk dit met zelf 400 meter lopen in 1 keer of 4 x 100 meter aflossing lopen.

Even een offtopic opmerking: het maar een idee, maar als het om eenmalige zaken bestanden etc gaat kun je beter doen zoals iemand die ik ken met familie in china. Zij zenden gewoon een sd card met gegevens op via UPS. gaat vlugger dan uploaden/downloaden, vooral als we het over bvb 4, 8, 16 of zelf 32GB hebben. En een sd card/usb stick in china kost nu ook weer niet zoveel he.

BvdHeide · #12 (**permalink**) 15 September 2009, 23:51

Bedankt voor je reactie The-Boss. Ik vroeg me gewoon af waarom die downloads vanuit het verre buitenland nou zo traag verliepen. De poging van een vriend van me was daarom ook een leuke testcase om eens te kijken hoe de connectiviteit verliep van China naar Nederland.

Kort samengevat ligt de langzame downloadsnelheid vanuit China dus niet aan de transitproviders maar meer aan de geografische afstand tussen Nederland en China als ik het goed begrijp? Ik heb al naar diverse oplossingen of technieken zoals UDP en FTP gekeken die de snelheid zou kunnen bevorderen maar tot nu toe heb ik nog niks spectaculairs gezien behalve veel te dure CDN's waar ik weinig mee kan.

De vertraging qua surfen is niet zo'n ramp, vooral de trage inzakkende downloads zijn een vervelend. Tevens heb ik ook een vermoeden dat een hele wirwar aan transitnetwerken en vele hops ook de boel vertragen, is er dan geen oplossing waarbij al het verkeer geforceerd over één kwalitatief goed netwerk gaat? Een directe peer of transitverbinding met China? Waarom heeft niemand dan een directe peer of transit dan met China?

Even ter verduidelijking: Mocht mijn ISP dus gaan peeren (mpls tunnel) met een Chinese IX lost dat dus in principe niks op behalve de kortere route?

edit: Nou had ik zonet even dit (http://www.akamai.com/html/technology/dataviz2.html) voor me gehad. Zij beweren een directe verbinding te hebben met China die na hun zeggen beter is dan die gewoonlijk aangeboden wordt. Van stabiele downloads tot aan het minimale aantal hops tussen continenten, zou dat dan echt zo goed zijn? Wat is er dan zo uniek aan Akamai in vergelijking met andere transitproviders? Dan zouden er toch vast wel meer transitpartijen zijn die zich specialiseren op een China-Europa verbinding?

Bedankt voor jullie uitleg mensen, enkel de oplossing heb ik helaas nog niet gevonden.

pvdpf · #13 (**permalink**) 16 September 2009, 00:02

Ik weet niet of het bestaat of kan, maar neem beide een satteliet af bij dezelfde provider.
Deze routeerd het verkeer van zijn eigen ipadresses natuurlijk niet verder over het internet.
Maar satteliet is nou ook niet de meest snelle verbinding die er bestaat.

Maar zoals gezegd, weet niet of het kan met het feit dat china aan de andere kant van de wereld ligt en aan de stand van de sattelieten.
Maar dit schoot me zojuist te binnen.

BvdHeide · #14 (**permalink**) 16 September 2009, 00:19

Ik denk zelf dat satellietinternet geen optie is, volgens mij is het internet dan niet echt snel. Het meest logische voor mij is ergens een bakkie afnemen die een directe goede transit verbinding heeft met China, natuurlijk wil ik ook goed bereikbaar zijn in andere landen maar mijn prioriteit gaat wel uit naar landen zoals China.

The-BosS · #15 (**permalink**) 16 September 2009, 04:14

Citaat:

Oorspronkelijk geplaatst door BvdHeide

edit: Nou had ik zonet even dit (http://www.akamai.com/html/technology/dataviz2.html) voor me gehad. Zij beweren een directe verbinding te hebben met China die na hun zeggen beter is dan die gewoonlijk aangeboden wordt. Van stabiele downloads tot aan het minimale aantal hops tussen continenten, zou dat dan echt zo goed zijn? Wat is er dan zo uniek aan Akamai in vergelijking met andere transitproviders? Dan zouden er toch vast wel meer transitpartijen zijn die zich specialiseren op een China-Europa verbinding?

Akamaai is inderdaad een high-content provider met fibers in eigen beheer, dus wat op hun site staat zou wel eens waar kunnen zijn. Akamaai levert o.a. de update servers van Microsoft. Dit is een goede oplossing als je global loadbalance wil doen, je upload je content op de dichts bij zijnde akamaai server (tot zover ik weet staan (stonden) die bij globalswitch amsterdam). En zij verdelen (mirroren) het dan over hun global servers, zodat je content altijd op de dichts bij zijnde server geconnect wordt. Alleen is dit niet echt goedkoop

.

PS: Een punt dat veel mensen ook blijken te vergeten is de Great Firewall of China die voor problemen kan zorgen.