News Internetknoten: Datendurchsatz am DE-CIX durchbricht 5 Tbit/s

riloka schrieb:
Wenn du aber einen Spiegelserver hast, brauchst du nur 1mal Daten austauschen und hälst mehr Last im eigenen Netz die du dann eben nicht austauschen musst.

Schon klar. Keine Ahnung wie das bei Netflix ist, aber bei Youtube wird nicht alles gespiegelt. Sondern nur Videos, die auch oft abgerufen werden spiegelt Google in die entsprechende Region / den entsprechenden Spiegel.

Und bei kleinen Providern, wie zB meinem, steht sicher kein Spiegel im Netz :-) Da läuft das einfach über das Peering am DE-CIX.
 
strex schrieb:
Soll das ein Werbepost von Akamai sein?
Oder besser gesagt 9,7 Tbit/s. Noch besser gesagt lachhafte 63,41 Mbit/s pro Server.

Warum, weil nicht durch Akamai optimiert? Also ich kann bequem mit ein paar MB/s von meinem amerikanischen Server hier in Deutschland mit TCP downloaden. Da ist nichts optimiert mit einem CDN.

Es läuft so oft über einen PNI, IXP,.. wie oft es von einem Anwender aufgerufen wird, der keine direkt Verbindung zum Akamai AS hat. Das dürfte nicht wenige sein, wenn man sich so die AS Paths anschaut.

Akamai hat doch gar keine AS im eigentlichen Sinne wie es bei ISPs etc der Fall ist. Akamai hat seine Server in tausenden AS drin.
Zudem: Akamai hat nicht allein auf Videos den Fokus, sondern eben auf alle Arten von Inhalten: Websites, Multimedia, Applikationen. Und die Optimierungen sorgen ja dafür dass deutlich weniger Overhead ist, ansonsten wären das einige TBit/s mehr. Es ist soweit Skalierbar, dass ein einzelner Videostream durchaus 2-3stellige TBit/s an Traffic erzeugen können. Gab genug Beispiele in der Vergangenheit mit Millionen von Online-Zuschauern, bspw. bei den US-Wahlen.
Und klar kannst du als einzelner auf den Server in den USA zugreifen. Aber lass einmal ein paar Mio Menschen von Europa auf die US-Server von Netflix zugreifen. Die Untersee-Kabel machen zwar das eine oder andere TBit/s mit, aber eben nicht deutlich mehr.
Ohne Optimierungen geht die RTT über tausende KM - bspw. von USA nach Europa - total nach oben bei normalem TCP, weshalb entsprechend der Datendurchsatz extrem sinkt. 10 oder 5000 km machen eben einen Unterschied. Außerdem sind 80TB/60s = 1,33TB/s = 10,66Tb/s. Mag zwar wenig klingen, letztendlich läuft aber trotzdem 15-30% des weltweiten Traffics durch deren Server. Und natürlich sind 60Mbit/s pro Server nicht viel, aber letztendlich muss man bei einer weltweiten Infrastruktur für alles gewappnet sein. Und bei der Optimierung geht es nun wirklich nicht ausschließlich um einen großen Datendurchsatz. Latenz, Paketverlust usw sind ebenfalls sehr wichtig. Wobei Akamai auch die Kommunikation über tausende KM von GB-großen Dateien um das 2-5x beschleunigt.

Habe mich jetzt für meine Masterarbeit aktuell in genug Themen eingelesen, wenn auch ich noch nicht von allen Papern die Zusammenhänge exakt verstehe. Da ich vor 2-3 Tagen das Akamai-Paper für das Background-Kapitel genutzt habe, hab ich das noch ganz gut im Kopf.

Außerdem: Die Existenz von CDNs sorgt ja dafür, dass für deinen Datenverkehr Platz im Unterseekabel ist.
Ergänzung ()

DonConto schrieb:
Schon klar. Keine Ahnung wie das bei Netflix ist, aber bei Youtube wird nicht alles gespiegelt. Sondern nur Videos, die auch oft abgerufen werden spiegelt Google in die entsprechende Region / den entsprechenden Spiegel.

Und bei kleinen Providern, wie zB meinem, steht sicher kein Spiegel im Netz :-) Da läuft das einfach über das Peering am DE-CIX.

YouTube hat ohnehin nur etwa 50 Standorte. Hot videos sind zumeist an den primary locations (was die meisten davon sind), cold videos werden durch redirection von anderen locations oder vom datacenter geholt.
Ergänzung ()

Holzkopf schrieb:
Ja aus USA geht heute ohne weiteres mit mehreren Mbit/s
Hir mal aus USA Washington DC

Code:
--2015-12-10 18:38:26--  http://speedtest.wdc01.softlayer.com/downloads/test1000
.zip
Resolving speedtest.wdc01.softlayer.com (speedtest.wdc01.softlayer.com)... 208.4
3.102.250
Connecting to speedtest.wdc01.softlayer.com (speedtest.wdc01.softlayer.com)|208.
43.102.250|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/zip]
Saving to: 'NUL'
NUL                  26%[====>                 ] 269.02M  24.0MB/s   eta 57s   ^

Nochmal 1-2 Std. warten, wenn in den USA alle von der Arbeit kommen und der Inter-Kontinental-Datenverkehr nach Europa stark ist sollte da was anderes rauskommen schätze ich.
 
yetisports schrieb:
Akamai hat doch gar keine AS im eigentlichen Sinne wie es bei ISPs etc der Fall ist. Akamai hat seine Server in tausenden AS drin.

Nö warum? Akamai hat sogar mehrere. Braucht die auch für die Bereitstellung der Adressräume für die Cache-Server. Das eigene AS 32787, AS 16625, AS 35994 und das übernommene von Prolexic. Das CDN verwendet das eigene AS zur Verteilung der Daten auf die Cache-Server. Die IP-Adressen der Cache-Server stammen aus dem AS von Akamai. Etwa einer bei der Telekom a104-87-240-51.deploy.static.akamaitechnologies.com (104.87.240.51), die IP dieses Servers stammt aus dem AS von Akamai steht aber bei der Telekom.

Du verstehst scheinbar nicht die Technologie dahinter. Akamai mietet sich bei der Telekom ein und baut mit seinem AS ein Peering/Transit Uplink mit dem der Telekom auf. Die Telekom schickt dann den Traffic über diesen Uplink zu den lokalen Server, abhängig des Standortes, da die Metric des Pfades bei den lokalen Server niedriger ist. Keine Zauberei, BGP ist dein Freund und ein paar Anycast Adressen noch.

Also nächstes mal besser bei der Schulung für Verkäufer aufpassen. Man möchte doch auch etwas verkaufen, aber nicht so.


yetisports schrieb:
Zudem: Akamai hat nicht allein auf Videos den Fokus, sondern eben auf alle Arten von Inhalten: Websites, Multimedia, Applikationen. Und die Optimierungen sorgen ja dafür dass deutlich weniger Overhead ist, ansonsten wären das einige TBit/s mehr. Es ist soweit Skalierbar, dass ein einzelner Videostream durchaus 2-3stellige TBit/s an Traffic erzeugen können. Gab genug Beispiele in der Vergangenheit mit Millionen von Online-Zuschauern, bspw. bei den US-Wahlen.
Und klar kannst du als einzelner auf den Server in den USA zugreifen. Aber lass einmal ein paar Mio Menschen von Europa auf die US-Server von Netflix zugreifen. Die Untersee-Kabel machen zwar das eine oder andere TBit/s mit, aber eben nicht deutlich mehr.

Dafür baut sich etwa Facebook ein RZ in Europa. Der Traffic ist dann kein Problem mehr. Auch Akamai, wie alle anderen CDN, zaubern nicht. Sie stellen eben nur lokale Routings zur Verfügung. Das kann Akamai jetzt auch nicht besonders besser als alle anderen CDNs. Netflix ist so schlau und stellt sich selbst bei den Providern unter. Man muss ja Akamai nicht für das teure CDN bezahlen, wenn man es auch selbst kann. Nicht umsonst ist Netflix von Akamai zu seinem eigenen gewechselt: http://blog.streamingmedia.com/2010...vel-3-and-limelight-pick-up-the-business.html

yetisports schrieb:
Ohne Optimierungen geht die RTT über tausende KM - bspw. von USA nach Europa - total nach oben bei normalem TCP, weshalb entsprechend der Datendurchsatz extrem sinkt. 10 oder 5000 km machen eben einen Unterschied. Außerdem sind 80TB/60s = 1,33TB/s = 10,66Tb/s.

Die Latenz macht jetzt aber nicht direkt der Bandbreite etwas aus. Sondern die Paketverlustrate. Denn es kann auch hohe Latenz und hohe Bandbreite geben, der Timeout der Pakete muss nur entsprechend hoch sein und das Window der Latenz und Bandbreite angepasst sein. Erst bei einem Verlust wird es interessant, mit dynamischen Window und Fast Retransmit schon lange gelöst. Eine Latenz (RTT) von 170ms macht heute kaum noch etwas aus. Nur die Fehlerrate (Packetloss) muss stimmen.

yetisports schrieb:
Mag zwar wenig klingen, letztendlich läuft aber trotzdem 15-30% des weltweiten Traffics durch deren Server. Und natürlich sind 60Mbit/s pro Server nicht viel, aber letztendlich muss man bei einer weltweiten Infrastruktur für alles gewappnet sein. Und bei der Optimierung geht es nun wirklich nicht ausschließlich um einen großen Datendurchsatz. Latenz, Paketverlust usw sind ebenfalls sehr wichtig. Wobei Akamai auch die Kommunikation über tausende KM von GB-großen Dateien um das 2-5x beschleunigt.

Wie will es Daten beschleunigen, wenn ich die hier in Deutschland schon mit voller Geschwindigkeit lade? Zauberei? Für ein Unternehmen, das in Europa, Amerika und Asien ein DC oder Server betreibt völlig unnötig. Das einzige wem das interessieren kann, sind die Werbeindustrie und einer der für kurzzeitige Downloads große Kapazitäten braucht.

yetisports schrieb:
Mag zwar wenig klingen, letztendlich läuft aber trotzdem 15-30% des weltweiten Traffics durch deren Server.

So richtig stimmt das nicht. 80TB pro Minute = 42EB pro Jahr. Geschätztes Volumen im Jahr 2016 soll bei 1,3ZB sein. Da der Anstieg den letzten Jahren über am DE-CIX wie auch bei anderen IXP weit größer als berechnet warum, dürfte er das jetzt schon weit überschritten haben. Das sind ja dann aktuell nur 3%. Also bitte Werbefolien korrigieren.

http://www.spiegel.de/netzwelt/web/...oll-sich-bis-2016-vervierfachen-a-836495.html


yetisports schrieb:
Habe mich jetzt für meine Masterarbeit aktuell in genug Themen eingelesen, wenn auch ich noch nicht von allen Papern die Zusammenhänge exakt verstehe. Da ich vor 2-3 Tagen das Akamai-Paper für das Background-Kapitel genutzt habe, hab ich das noch ganz gut im Kopf.

Na dann wird es Zeit nicht die Werbefolien zu studieren, sondern etwas technisches. Weil die Zahlen der Werbefolien kannst du runterbeten, aber am technischen Verständnis scheitert es ganz gut. Akamai Folien taugen für viel, meist zum heizen, aber nicht für den technischen Hintergrund.


yetisports schrieb:
Außerdem: Die Existenz von CDNs sorgt ja dafür, dass für deinen Datenverkehr Platz im Unterseekabel ist.

Die Existenz von CDNs sorgt dafür das vielen Unternehmen das Geld aus der Tasche gezogen wird, obwohl es nicht benötigt wird. CDNs haben es in Zukunft ziemlich schwer, denn die Cloud Provider mit Standorte in der ganzen Welt erlauben es ein eigenes CDN bei bedarf zu installieren. Technik und Software wird meist gleich mitgeliefert, aber um ein vielfaches günstiger. Wenn ich da für ein paar Tage ein CDN benötige, dann wende ich mich einfach an den Cloud Provider.

yetisports schrieb:
Nochmal 1-2 Std. warten, wenn in den USA alle von der Arbeit kommen und der Inter-Kontinental-Datenverkehr nach Europa stark ist sollte da was anderes rauskommen schätze ich.

Nope, alles mit voller Geschwindigkeit. Warum auch, wählt man den richtigen Provider mit passenden AS ist die Leitung eben nicht dicht.

Akamai ist heute ganz schön unter Druck. Google baut öffentliches CDN, Tier 1 Provider ala Level 3, ehemalige Kunden wie Netflix bauen ebenfalls eigene CDNs mit unter für die Öffentlichkeit. Akamai hat kein Alleinstellungsmerkmal mehr, Level 3 bietet die bessere Anbindung, Google die größeren Ressourcen und Netflix zahlt nicht mehr an Akamai. Und die hundert anderen CDNs von kleinem bis zum großen Geld gibt es auch noch. Aus diesem Grund hat sich Akamai auch Prolexic einverleibt, um in neue Geschäftsfelder zu investieren wenn CDN nicht mehr viel bringt.

Und andere können es auch besser: https://thedotproduct.org/a-simple-and-rough-comparison-of-akamai-and-cloudfront-cdns/
 
Zuletzt bearbeitet:
Ich habe mehrmals schon gelesen dass diese peaks oft entstehen wenn ein neues iOS oder OS X zum Download bereit stand. Würde ja hier auch genau zutreffen da Apple alle vier betriebssyst me aktualisiert hat. Dachte windows10 Veröffentlichung würde das dieses Jahr toppen aber da habe ich mich wohl geirrt.
 
yetisports schrieb:
Nochmal 1-2 Std. warten, wenn in den USA alle von der Arbeit kommen und der Inter-Kontinental-Datenverkehr nach Europa stark ist sollte da was anderes rauskommen schätze ich.

Jetzt sollten in den USA alle von der Arbeit da sein, downloade in Steam gerade mit fast 60MB/s von Server in Pittsburgh (sprich nichtmal direkt East Coast)
 
Marcel55 schrieb:
Und mit welcher Hardware will man die Auslasten?
Tellerrand? Warum gehen in diesenm Forum immer alle davon aus, dies privat zu verbrauchen? :rolleyes:

Die 100GBit-Leitung lastest du mit den Daten vom Atlas-Detektor vom Cern voll aus: https://de.wikipedia.org/wiki/ATLAS_(Detektor)
In der c´t lief Jahrelang eine Werbung von HP, das diese zwischen 2000 und 2005 20 Institute in Europa mit 1GBit-SDSL-Leitungen ans Cern angebunden hatten, um 10% (!) der anfallenden Datenmenge vom Atlas-Detektor auf die Großrechner der Institute zu verteilen.
 
Autokiller677 schrieb:
Das gilt aber halt nur wenn man einen Gamer im Haushalt hat, für den der Ping wichtig ist. Ansonsten kann man selbst auf einer 6Mbit Leitung bei meinen Eltern problemlos mit Amazon Prime Streamen und nebenher mit mehreren Leuten surfen.
Für Normalverbraucher, die nicht gamen, ist aktuell alles ab 6-8 Mbit noch genug, um ohne lange Wartezeiten Surfen und Streamen zu können. Parallel Streamen dann mit etwas geringerer Qualität, aber selbst das geht noch. 50 oder 100 Mbit sind nice-to-have, aber selbst für eine Familie im Normalfall noch Overkill. Wie oft laufen denn dann wirklich 3-4 Streams parallel? Bei uns vielleicht mal 2, aber oft guckt man ja etwas zusammen, so dass 4 ziemlich unrealistisch sind.

Hi!

Ok sehr komisch hab eben probiert da ich ned so oft youtube sehe aber 1080 p scheint mit meiner gammel 5,5 mbit nun zu funktionieren beim streamen .
Das letzte mal ging das noch nicht. Scheint als habe youtube hier bis jetzt gebremst.
Komischerweise ist genau das Online Gaming das wo ich keine Probleme habe obwohl nur 5,5 Mbit hier hab ich 30-40 ms was absolut ok ist da ich nicht professionell Spiele.
Andere haben hier mit 100mbit auch keine besseren Pings, aber auch das hängt wohl sehr vom anbieter ab wie es scheint.

Ansonsten hast du recht für mich persönlich wären so 100mbit nur nice to have für Steam Downloads aber kein muss.
 
strex schrieb:
Du verstehst scheinbar nicht die Technologie dahinter. Akamai mietet sich bei der Telekom ein und baut mit seinem AS ein Peering/Transit Uplink mit dem der Telekom auf. Die Telekom schickt dann den Traffic über diesen Uplink zu den lokalen Server, abhängig des Standortes, da die Metric des Pfades bei den lokalen Server niedriger ist. Keine Zauberei, BGP ist dein Freund und ein paar Anycast Adressen noch.
Aber CDNs verbessert doch auch das BGP-Routing. Normales BGP-Routing funktionieren ja nur nach der Metric "möglichst wenige AS-Hops", aber nicht nach "bring mich am schnellsten zum Ziel". Ok, natürlich müssen noch die BGP-Policies der Provider berücksichtigt werden.

strex schrieb:
Die Latenz macht jetzt aber nicht direkt der Bandbreite etwas aus. Sondern die Paketverlustrate. Denn es kann auch hohe Latenz und hohe Bandbreite geben, der Timeout der Pakete muss nur entsprechend hoch sein und das Window der Latenz und Bandbreite angepasst sein. Erst bei einem Verlust wird es interessant, mit dynamischen Window und Fast Retransmit schon lange gelöst. Eine Latenz (RTT) von 170ms macht heute kaum noch etwas aus. Nur die Fehlerrate (Packetloss) muss stimmen.
Die ISPs benutzen doch Standard-TCP, oder? CDNs sorgen doch mit einem größeren Window und Multipath dafür, dass es schneller geht.

strex schrieb:
So richtig stimmt das nicht. 80TB pro Minute = 42EB pro Jahr. Geschätztes Volumen im Jahr 2016 soll bei 1,3ZB sein. Da der Anstieg den letzten Jahren über am DE-CIX wie auch bei anderen IXP weit größer als berechnet warum, dürfte er das jetzt schon weit überschritten haben. Das sind ja dann aktuell nur 3%. Also bitte Werbefolien korrigieren.

http://www.spiegel.de/netzwelt/web/...oll-sich-bis-2016-vervierfachen-a-836495.html
Meine Zahlen von (vermutlich) 2015 mit Vorhersagen für 2016 zu vergleichen ist natürlich auch nicht gerade fair. Cisco erwartet übrigens 2ZB für 2019 und >1ZB für 2016, 2014 waren es vermutlich 734EB. Ist aber auffällig dass bei Traffic-Peaks auch CDNs deutlich mehr genutzt werden. Für ein CDN, welches nicht den Fokus auf traffic-intensive Applikationen hat, wie bspw. YouTube oder Netflix (die auch grob bei 10% sind), finde ich den Traffic aber sehr beachtlich.

strex schrieb:
Na dann wird es Zeit nicht die Werbefolien zu studieren, sondern etwas technisches. Weil die Zahlen der Werbefolien kannst du runterbeten, aber am technischen Verständnis scheitert es ganz gut. Akamai Folien taugen für viel, meist zum heizen, aber nicht für den technischen Hintergrund.
Sind ja keine Marketingfolien, sondern (ein zugegebenermaßen nicht mehr ganz aktuelles) Paper von 2010 was es ja immerhin ins SIGOPS Journal geschafft hat. Aber klar, will jetzt nicht bestreiten dass das etwas einseitig beschrieben ist und ich auf IXP-Ebene vor allem noch ein wenig mehr verstehen muss. Hab ja aber noch knapp 5 Monate Zeit; wobei das ja eh nur ein Einstieg in das eigentliche Thema wird.

strex schrieb:
Die Existenz von CDNs sorgt dafür das vielen Unternehmen das Geld aus der Tasche gezogen wird, obwohl es nicht benötigt wird. CDNs haben es in Zukunft ziemlich schwer, denn die Cloud Provider mit Standorte in der ganzen Welt erlauben es ein eigenes CDN bei bedarf zu installieren. Technik und Software wird meist gleich mitgeliefert, aber um ein vielfaches günstiger. Wenn ich da für ein paar Tage ein CDN benötige, dann wende ich mich einfach an den Cloud Provider.
CDNs sollten aber eine weitaus bessere Skalierbarkeit gewährleisten können, oder nicht? (Laut Werbe-Paper :P). Glaub kaum dass ISPs hunderte Tbps stämmen könnten. Das Amazon Cloud Computing EC2 wird ja bspw. durch Akamai optimiert.

strex schrieb:
Akamai ist heute ganz schön unter Druck. Google baut öffentliches CDN, Tier 1 Provider ala Level 3, ehemalige Kunden wie Netflix bauen ebenfalls eigene CDNs mit unter für die Öffentlichkeit. Akamai hat kein Alleinstellungsmerkmal mehr, Level 3 bietet die bessere Anbindung, Google die größeren Ressourcen und Netflix zahlt nicht mehr an Akamai. Und die hundert anderen CDNs von kleinem bis zum großen Geld gibt es auch noch. Aus diesem Grund hat sich Akamai auch Prolexic einverleibt, um in neue Geschäftsfelder zu investieren wenn CDN nicht mehr viel bringt.
Und andere können es auch besser: https://thedotproduct.org/a-simple-and-rough-comparison-of-akamai-and-cloudfront-cdns/
Öffentlich heißt ja nicht kostenlos. Irgendwo her müssen auch Level3 und Google das Geld dafür nehmen. Und Konkurrenz belebt ja das Geschäft. Wäre ja schlimm wenn Akamai das Amazon der CDNs bleibt.

Für die Allgemeinheit wäre es ohnehin das Beste wenn ISPs und CDNs kooperieren. CDNs kennen die Serverauslastung und ISPs wissen über die Standorte der Nutzer und die Netzwerkbedingungen Bescheid.
 
Zuletzt bearbeitet:
yetisports schrieb:
Aber CDNs verbessert doch auch das BGP-Routing. Normales BGP-Routing funktionieren ja nur nach der Metric "möglichst wenige AS-Hops", aber nicht nach "bring mich am schnellsten zum Ziel". Ok, natürlich müssen noch die BGP-Policies der Provider berücksichtigt werden.

Das CDN hat direkt mit dem BGP Routing zunächst nichts zu tun. Nur man verwendet im CDN eben diese Techniken, damit der Traffic vom Abrufenden schnell im Zielnetz des CDN Providers kommt. Viele PoPs ermöglichen eben damit das es schnell den Übergang findet. Dazu mietet sich der CDN Anbieter am Besten direkt bei ISP ein und baut ein Peering/Transit an diesem Standort auf. Hat der ISP noch ein anderen Standort, mietet er sich dort wieder ein, um den Traffic an diesem Standort direkt zu übernehmen. Am Besten stellt er dann dort noch ein paar Mirror Server auf und die Sache läuft. Um das jetzt einmal einfach auszudrücken.

yetisports schrieb:
Die ISPs benutzen doch Standard-TCP, oder? CDNs sorgen doch mit einem größeren Window und Multipath dafür, dass es schneller geht.

Ne, das ist eine Sache des TCP Stacks des Server und des TCP Stacks des Clients. Fast Retransmit und co. sind schon seit langer Zeit in den Stacks verfügbar, wie auch ein dynamisches Window. Akamai versucht nur den Stack des Servers zu optimieren, das schaffen viele andere aber auch und ist meistens nur Schlangenöl. Das kann jeder der einen Server hat auch selbst. Einfach etwas Zeit für Tests mitbringen und in der sysctl.conf die TCP Parameter anpassen.

yetisports schrieb:
Sind ja keine Marketingfolien, sondern (ein zugegebenermaßen nicht mehr ganz aktuelles) Paper von 2010 was es ja immerhin ins SIGOPS Journal geschafft hat. Aber klar, will jetzt nicht bestreiten dass das etwas einseitig beschrieben ist und ich auf IXP-Ebene vor allem noch ein wenig mehr verstehen muss. Hab ja aber noch knapp 5 Monate Zeit; wobei das ja eh nur ein Einstieg in das eigentliche Thema wird.

Bei Papers von Anbieter muss man eben aufpassen. Denn die haben meistens das Ziel das Produkt zu verkaufen, mehr nicht.

yetisports schrieb:
Meine Zahlen von (vermutlich) 2015 mit Vorhersagen für 2016 zu vergleichen ist natürlich auch nicht gerade fair. Cisco erwartet übrigens 2ZB für 2019 und >1ZB für 2016, 2014 waren es vermutlich 734EB. Ist aber auffällig dass bei Traffic-Peaks auch CDNs deutlich mehr genutzt werden. Für ein CDN, welches nicht den Fokus auf traffic-intensive Applikationen hat, wie bspw. YouTube oder Netflix (die auch grob bei 10% sind), finde ich den Traffic aber sehr beachtlich.

Ich habe die Status Anzeige von Akamai verwendet (2015) und den geschätzten Wert von 2016. Ob das jetzt 1,2ZB oder 1,4ZB sind ist ja fast egal. Es ändert nichts an der Sache das es keine 30% sind sondern im 3-4% Bereich. Solche Peaks hat der DE-CIX und andere auch, es sind wie es sind Peaks. Auch Akamai hat solche Peaks wenn etwa Apple ein iOS ausrollt. Sagen aber nichts aus, über die Bandbreite im Mittel. Davon könnte man erst berechnen ob CDNs einen überproportionalen Anstieg an Volumen erfahren oder die normale Steigerung des Internets sind.

yetisports schrieb:
CDNs sollten aber eine weitaus bessere Skalierbarkeit gewährleisten können, oder nicht? (Laut Werbe-Paper :P). Glaub kaum dass ISPs hunderte Tbps stämmen könnten. Das Amazon Cloud Computing EC2 wird ja bspw. durch Akamai optimiert.

Jetzt muss erst einmal der Begriff ISP geklärt sein. Sprechen wir von Carrier oder Compute-Anbieter? Die Carrier haben das, brauchen es ja auch, um den Traffic von Anwender zum CDN zu übertragen sowie alle anderen Daten des Anwenders die nicht ein CDN zum Ziel haben. Akamai nutzt ja selbst die Anbieter um seinen Traffic los zu kriegen. Bei Compute-Anbieter gibt es durchaus viele die Uplinks im Tbit/s Bereich haben. Im besonderen die, welche zig DCs in der Welt betreiben. OVH, Leaseweb, Google, Amazon,.. so wenig sind das nicht.

yetisports schrieb:
Öffentlich heißt ja nicht kostenlos. Irgendwo her müssen auch Level3 und Google das Geld dafür nehmen. Und Konkurrenz belebt ja das Geschäft. Wäre ja schlimm wenn Akamai das Amazon der CDNs bleibt.

Korrekt aber deutlich günstiger als Akamai. Er gibt sich ja aus der Sache das diese Unternehmen bereits zig DCs weltweit für die eigenen Dienste betreiben und so kostengünstig eine Leistung anbieten können. Akamai als Dienstleister verkauft die Lösung, muss extra die Standorte für diese Leistung bezahlen und werden nicht mitfinanziert von den Kerngeschäften der anderen. Google oder Amazon brauchen dies für ihr Kerngeschäft, stellen diese aber kostengünstig zur Verfügung um die Kosten dafür zu verringern. Das ermöglich eben einen günstigen Preis.

Akamai ist mit seinem CDN nicht alleine. Es gibt zig Anbieter die dasselbe bieten, aber statt als Enterprise-Produkt viel günstiger. Carrier und co. sind auch in das Geschäft eingestiegen, da sie ja bereits eh zig DCs weltweit betreiben und so noch etwas Geld abgrasen können. So macht das etwa Level 3.

yetisports schrieb:
Für die Allgemeinheit wäre es ohnehin das Beste wenn ISPs und CDNs kooperieren. CDNs kennen die Serverauslastung und ISPs wissen über die Standorte der Nutzer und die Netzwerkbedingungen Bescheid.

Der Carrier oder ISP wie sicherlich nicht gern seine Leistungsdaten an Akamai weitergeben. Denn das ist ein Betriebsgeheimnis. Das Beste wäre ein Carrier weltweit mit einem CDN, denn der würde die Auslastung und Traffic Flows aller Uplinks kennen und dementsprechend optimieren. Da läuft es bei Akamai eben auch nicht so rund, rollt Apple ein iOS Update über Akamai aus und zack ist der Download nur noch bei ein paar KB/s. So erst bei mir geschehen mit iOS 9.2.

Akamai ist viel zu teuer für das was sie (CDN) anbieten. Aus diesem Grund hat Amazon sein eignes aufgebaut und stellt sukzessive um. Auch Apple will Akamai los werden und baut sein eigenes auf. Netflix hat das schon früh erkannt und hat seine eigenen Transit zu den Carrier, um Kosten für den Traffic zu sparen.

Apropos CDN, das kann heute jeder selbst bauen. Man braucht nur ein paar vServer mit Nginx, Varnish und co. und einen GeoDNS Anbieter. Schon hat man sein eigenes CDN für wenig Geld. Da eigenet sich etwa digitalocean perfekt, bietet doch als Compute-Anbieter viele Standorte weltweit.

http://www.scalescale.com/rolling-your-own-cdn-build-a-3-continent-cdn-for-25-in-1-hour/
 
Zuletzt bearbeitet:
strex schrieb:
Der Carrier oder ISP wie sicherlich nicht gern seine Leistungsdaten an Akamai weitergeben. Denn das ist ein Betriebsgeheimnis. Das Beste wäre ein Carrier weltweit mit einem CDN, denn der würde die Auslastung und Traffic Flows aller Uplinks kennen und dementsprechend optimieren. Da läuft es bei Akamai eben auch nicht so rund, rollt Apple ein iOS Update über Akamai aus und zack ist der Download nur noch bei ein paar KB/s. So erst bei mir geschehen mit iOS 9.2.

Akamai ist viel zu teuer für das was sie (CDN) anbieten. Aus diesem Grund hat Amazon sein eignes aufgebaut und stellt sukzessive um. Auch Apple will Akamai los werden und baut sein eigenes auf. Netflix hat das schon früh erkannt und hat seine eigenen Transit zu den Carrier, um Kosten für den Traffic zu sparen.

Apropos CDN, das kann heute jeder selbst bauen. Man braucht nur ein paar vServer mit Nginx, Varnish und co. und einen GeoDNS Anbieter. Schon hat man sein eigenes CDN für wenig Geld. Da eigenet sich etwa digitalocean perfekt, bietet doch als Compute-Anbieter viele Standorte weltweit.

http://www.scalescale.com/rolling-your-own-cdn-build-a-3-continent-cdn-for-25-in-1-hour/

Carrier und ISPs haben doch aber das Problem, dass sie zwar - wenn überhaupt - weltweit verteilt sind, aber dann eher in Form von ein paar dutzend großen DCs. Quasi dann ein DC-CDN, dass aber eben in der Summe immer weiter vom Kunden weg sein wird als highly distributed CDNs mit tausenden Standorten. So wie ich das immer lese sind DCs teuer, groß, komplex und können auch "nur" 1Tbps (von der Größenordnung) erreichen. Bei CDNs gilt ja eher "Kleinvieh macht auch Mist", weil es ganz viele kleine Server sind, die durch das CDN-Overlay besser erweiterbar sind.
Zu den Preisen kann ich nix sagen, da glaube ich dir einfach mal. Kann mir aber auch vorstellen dass Netflix und Co sich nicht von anderen Monopolisten (wie Akamai bei CDNs) abhängig machen wollen und eben als CP darauf setzen wollen das selbst zu machen. YouTube ist ja auch letztendlich ein CDN, wobei dann eher ein DC-CDN. Je nachdem wie breit man CDN definiert hat ja jeder große CP ein CDN, da man mehr als 1 oder 2 DCs benötigt. Und ein CDN benötigt ja letztendlich nur ne handvoll Server, die weitweit verteilt sind - oder wo man eben gerne Daten verteilen will; ist ja in dem Sinne keine Rocketscience.

Aber deine Einwände behalte ich mir definitiv nochmal, wenn ich mir die 1 dutzend Paper zu ISP-CDN-Collaboration im Detail angucke. Wird ein interessantes Wochenende. :D

Hast du eigentlich beruflich (T-Systems?) damit zu tun oder wieso kennst du dich so gut damit aus? Kannst das auch (notfalls) gerne per PN beantworten, oder es eben offen lassen. ;)
 
Zuletzt bearbeitet:
yetisports schrieb:
Carrier und ISPs haben doch aber das Problem, dass sie zwar - wenn überhaupt - weltweit verteilt sind, aber dann eher in Form von ein paar dutzend großen DCs.

Nichts anderes macht Akamai auch. Sie betreiben sogar nicht einmal die DCs sondern mieten sich unter. Akamai hat aktuell auch nur um die 70 Standorte. Von tausenden ist da nicht die Rede.

https://cdnify.com/blog/akamai-vs-cdnify/

yetisports schrieb:
So wie ich das immer lese sind DCs teuer, groß, komplex und können auch "nur" 1Tbps (von der Größenordnung) erreichen. Bei CDNs gilt ja eher "Kleinvieh macht auch Mist", weil es ganz viele kleine Server sind, die durch das CDN-Overlay besser erweiterbar sind.

Die Server von Akamai stehen auch nur in normalen DCs anderer Unternehmen. Die maximal mögliche Bandbreite der DCs ist nicht begrenzt, sondern ergibt aus den Uplinks die es nutzt. Wenn ich will kann ich auch ein DC mit 1000 Tbit/s bauen, wenn ich genug Geld habe und das brauche. Ein DC-CDN gibt es nicht. Das ist nur eine Anwendung innerhalb eines DCs, nämlich ein CDN.

yetisports schrieb:
Hast du eigentlich beruflich (T-Systems?) damit zu tun oder wieso kennst du dich so gut damit aus? Kannst das auch (notfalls) gerne per PN beantworten, oder es eben offen lassen. ;)

Ich plane und entwickle jetzt schon einige Jahre DCs und Weitverkehrsnetze ;)
 
strex schrieb:
Nichts anderes macht Akamai auch. Sie betreiben sogar nicht einmal die DCs sondern mieten sich unter. Akamai hat aktuell auch nur um die 70 Standorte. Von tausenden ist da nicht die Rede.

https://cdnify.com/blog/akamai-vs-cdnify/
Dann macht aber der Globus von Akamai gar keinen Sinn: http://wwwnui.akamai.com/gnet/globe/index.html
Sie mieten sich ja dann wohl eben in sehr viele DCs ein.
strex schrieb:
Die Server von Akamai stehen auch nur in normalen DCs anderer Unternehmen. Die maximal mögliche Bandbreite der DCs ist nicht begrenzt, sondern ergibt aus den Uplinks die es nutzt. Wenn ich will kann ich auch ein DC mit 1000 Tbit/s bauen, wenn ich genug Geld habe und das brauche. Ein DC-CDN gibt es nicht. Das ist nur eine Anwendung innerhalb eines DCs, nämlich ein CDN.

OK, ein DC ist ja letztendlich ein Server-Cluster. Wobei ja 6.000 Server in Frankfurt schon ne Hausnummer sind. Gibt ja weltweit nur 1-2 Standorte mit gleicher Größe bei Akamai.
strex schrieb:
Ich plane und entwickle jetzt schon einige Jahre DCs und Weitverkehrsnetze ;)
Oha, cool. :D

Kannst ja mal hier auf Seite 3 schauen wenn du Lust hast: https://www.akamai.com/us/en/multim...nce-on-the-internet-technical-publication.pdf Da steht das mit "Big Data Center CDNs" und "Highly Distributed CDNs" bei den "Four Approaches". Auf der gleichen Seite auch die Abbildung zum Datendurchsatz über eine lange Strecke.
PS: Ich gehe davon aus dass du mit DC Data Center gemeint hast. ^^
 
UweW. schrieb:
Tellerrand? Warum gehen in diesenm Forum immer alle davon aus, dies privat zu verbrauchen? :rolleyes:
Genau das habe ich doch nicht gemacht, ich habe es erst mal von Hardware-Seite betrachtet, da wird es schon schwierig sowas zu ermöglichen. Selbst meine 100Mbit-Leitung bringt teils meine Festplatte an ihre Grenzen wenn Steam z.B. Updates macht, weil die einfach zu langsam rödelt...
Dennoch weiß ich ja dass es für alles einen Nutzen und eine Möglichkeit gibt.

thrawnx schrieb:
Jetzt sollten in den USA alle von der Arbeit da sein, downloade in Steam gerade mit fast 60MB/s von Server in Pittsburgh (sprich nichtmal direkt East Coast)
Wo bekommt man denn bitte 60MB/s? :freak:

Gut, in der Uni habe ich schon Datenraten über 500Mbit/s gemessen je nach dem wie viel gerade das Internet nutzen...aber privat bekommt man ja nicht mehr als 200Mbit/s derzeit :(
 
yetisports schrieb:
Dann macht aber der Globus von Akamai gar keinen Sinn: http://wwwnui.akamai.com/gnet/globe/index.html
Sie mieten sich ja dann wohl eben in sehr viele DCs ein.

Die Frage ist was da eingezeigt werden soll? Sind die Punkte PoPs? Stellen die dort den gesamten Cache zur Verfügung. Ich vermute eher nicht, denn die Folien geben explizit nur 74 Locations mit voller Replikation an. Dann sind das nur GeoDNS Server, die die Anfrage für den DNS lokal beantworten der reale Content aber weiter weg liegt. Das soll die Auflösung der IP-Adresse beschleunigen. Wir reden hier aber von unter 10ms, das ist kaum bemerkbar. Akamai schweigt dazu aber immer gern.

Die Verbindung von Zürich zu Akamai ist zum Beispiel nicht besonders gut. Jedenfalls aus dem AS 12586:

traceroute to a1850.dspb.akamai.net (80.239.137.146), 64 hops max, 52 byte packets
1 206.123.147.4 (206.123.147.4) 1547.396 ms 23.261 ms 22.999 ms
2 5.230.5.137 (5.230.5.137) 26.149 ms 25.675 ms 24.061 ms
3 c07.dwh.fra.ghostnet.de (5.175.255.132) 25.090 ms 24.895 ms 23.368 ms
4 ffm-b2-link.telia.net (213.248.72.117) 24.483 ms 25.151 ms 32.466 ms
5 ffm-bb1-link.telia.net (62.115.140.20) 25.972 ms
ffm-bb2-link.telia.net (62.115.142.60) 59.009 ms
ffm-bb2-link.telia.net (62.115.142.92) 24.365 ms
6 hbg-bb4-link.telia.net (62.115.138.177) 33.228 ms
hbg-bb4-link.telia.net (62.115.115.62) 43.149 ms 34.221 ms
7 adm-bb4-link.telia.net (62.115.136.124) 39.787 ms
adm-bb3-link.telia.net (62.115.113.244) 45.126 ms
adm-bb3-link.telia.net (80.91.248.210) 38.208 ms
8 adm-b5-link.telia.net (62.115.140.187) 39.743 ms
adm-b5-link.telia.net (62.115.140.193) 40.917 ms
adm-b5-link.telia.net (213.155.136.249) 39.415 ms
9 80-239-137-146.customer.teliacarrier.com (80.239.137.146) 39.972 ms 39.193 ms 41.447 ms

Deshalb beeinflusst meist nich der direkte Standort (physikalisch) ob es eine gute Verbindung wird oder nicht, sondern das Routing des Home AS bzw. deren Upstream.


yetisports schrieb:
OK, ein DC ist ja letztendlich ein Server-Cluster. Wobei ja 6.000 Server in Frankfurt schon ne Hausnummer sind. Gibt ja weltweit nur 1-2 Standorte mit gleicher Größe bei Akamai.

In Frankfurt am DE-CIX hat halt den großen Vorteil das man ziemlich viele Provider erreichen kann ohne sich direkt bei diesen unter zu mieten. Den gibt es auch am AMIX. Deshalb betreibt etwa OVH ein eigenes Weitverkehrsnetz damit der Traffic direkt an den lokalen IXP des Landes ausgetauscht wird.

6.000 Server sind eigentlich ne kleine Nummer. Gebaut wurden DCs schon für 1 Million Server oder mehr. OVH hat sich etwa eines für bis zu 720.000 Server hingestellt. Wenn der Container-Ausbau derzeit auch nur bis 360.000 umfasst. Paar größere DCs von OVH: https://www.ovh.com/us/about-us/datacenters.xml

Zeigt das sehr schön mit Auslastung: http://weathermap.ovh.net/#europe


yetisports schrieb:
Kannst ja mal hier auf Seite 3 schauen wenn du Lust hast: https://www.akamai.com/us/en/multim...nce-on-the-internet-technical-publication.pdf Da steht das mit "Big Data Center CDNs" und "Highly Distributed CDNs" bei den "Four Approaches". Auf der gleichen Seite auch die Abbildung zum Datendurchsatz über eine lange Strecke.
PS: Ich gehe davon aus dass du mit DC Data Center gemeint hast. ^^

Ich kenne viele der Folien und Whitesheets. Sind doch öfters mal welche von Akamai bei uns da. Die Werte muss man aber immer unter Vorbehalt sehen. Denn der Durchsatz wo angegeben wird ist immer Carrier Abhängig und deren Peering/Transit Strategie. Schlechtes Peering oder schlechter Transit und du bekommst Probleme. Auch wenn die Uplinks überlaufen. Dann kann aber auch Akamai nicht mehr helfen, weil sämtliche Packets in's Zielnetz durch den Flaschenhals müssen. Heutzutage sind aber Links zwischen Europa und Nord Amerika kein Probleme mehr. Man darf dann halt nicht auf Ramsch Traffic ala Congent setzen.
 
Zuletzt bearbeitet:
Marcel55 schrieb:
Wo bekommt man denn bitte 60MB/s? :freak:

Gut, in der Uni habe ich schon Datenraten über 500Mbit/s gemessen je nach dem wie viel gerade das Internet nutzen...aber privat bekommt man ja nicht mehr als 200Mbit/s derzeit :(

Von einem Dedicated aus. Ging ja nur darum zu zeigen dass der Speed nach Amerika heutzutage kein Problem mehr ist.
 
Marcel55 schrieb:
Genau das habe ich doch nicht gemacht, ich habe es erst mal von Hardware-Seite betrachtet, da wird es schon schwierig sowas zu ermöglichen. Selbst meine 100Mbit-Leitung bringt teils meine Festplatte an ihre Grenzen wenn Steam z.B. Updates macht, weil die einfach zu langsam rödelt...
Dennoch weiß ich ja dass es für alles einen Nutzen und eine Möglichkeit gibt.


Wo bekommt man denn bitte 60MB/s? :freak:

Gut, in der Uni habe ich schon Datenraten über 500Mbit/s gemessen je nach dem wie viel gerade das Internet nutzen...aber privat bekommt man ja nicht mehr als 200Mbit/s derzeit :(

Deine Festplatte ist garantiert nicht mit der 100MBit Leitung überfordert. Das sind gerade mal 12,5MB/s und eine moderne Festplatte schreibt mit 100 bis 200MB/s...
 
Ja, das tut sie, im seriellen Schreiben/Lesen, aber nicht, wenn diese Festplatte zu über 90% belegt ist und dazu relativ fragmentiert (wobei, das nicht mal, aber, trotzdem lahm). Wenn man ein neues Spiel runterlädt, läuft das meistens durch, aber bei Updates habe ich es häufiger dass die Festplatte limitiert. Nicht selten sogar bei der 16K Leitung.
 
Vitec schrieb:
Hi!

Ok sehr komisch hab eben probiert da ich ned so oft youtube sehe aber 1080 p scheint mit meiner gammel 5,5 mbit nun zu funktionieren beim streamen .
Das letzte mal ging das noch nicht. Scheint als habe youtube hier bis jetzt gebremst.

Vor allem werden auch die Algorithmen immer besser, und Google / YT ist da ganz vorne mit dabei. Während Amazon Prime es z.B. nichtmal schafft, mir dauerhaft HD zu liefern (nichtmal FHD) und oft auf SD zurückfällt, schafft YT halt durchgehend 1080p. Und bei heise stockt auch das 360p Video gerne mal.

Es liegt also neben der Bandbreite auch ganz extrem am Videoplayer, Anbieter und der Technologie dahinter.
 
Thaxll'ssillyia schrieb:
Ich bin ja mal dafür 99 % der Streaming Videos zu unterbinden, da ist dermaßen viel Blödsinn dabei dass man sich nur an den Kopf greifen kann...Und schon wäre wieder deutlich mehr Traffic für sinnvolle Sachen dabei.

Dann kann man auch 99% aller Kommentare unterbinden, da ist auch jede Menge Blödsinn dabei:-)
 
Zurück
Oben