Posted on

Spatz im Brot

(Blogged via flickr)

Stadtspatzen sind wirklich schlauer und frecher; dieser hier hat sich am Brot schlaraffiert :-)

Kamera: Nokia N900 (Brennweite 5.2mm, f/2.8)

Posted on

Die Mär von den überbordenden Netzkosten

Schick, ein Blogeintrag thematisiert, was augenscheinlich schon viele vermutet und teils auch ‘ermessen’ haben — und die Telekom reagiert:

Verschwörungstheoretisch würde es ins Bild passen: Die Telekom denkt über Serviceklassen für gesicherte Qualitäten nach und um Druck zu machen, drosselt sie die Kapazität bzw. zahlt dem US-Provider nicht genug Geld für Aufstockung. Achtung! Letzteres müsste eigentlich zum Aufschrei der Community führen, denn dann würde die Telekom ja aktiv durch andere Netzbetreiber diskriminiert – es sei denn, sie zahlt! […]

 
Netter Versuch, aber von der bedingungslosen Bandbreite bis zum Abwinken sind sowohl die Kunden der Telekom als auch die Telekom als Kunde anderer Anbieter noch weit entfernt. (Kostenloses) Peering ist doch nur eine vereinfachte Verrechnung: ich will 500 TB in Dein Netz schieben, Du 500 TB in meins, anstatt daß Du mir 500 TEUR/Monat in Rechnung stellst und ich Dir 500 TEUR/Monat, machen wir’s zu jeweils eigenen Kosten. Das funktioniert unter gleich großen Spielern ganz gut, bei einem großen Sauger aus US-Quellen wie dem (Endkunden-) Netz der Telekom wird jene für adäquate Anbindung an das Netz mit den Informationen, die die Kunden wollen, eben bezahlen müssen — entweder mit relevanten Inhalten für US-Bürger oder angeschlossene Netze oder eben mit harten Euronen. Denn, ja, Netze kosten, einmal verbuddeln und vergessen reicht nicht.

Aber jetzt wieder zum Thema aus dem Blog stadt-bremerhaven: Ich weiß nicht, was der Hintergrund bei anderen Netzbetreibern ist, bei der Telekom ist die Beobachtung aber richtig – ja, es läuft langsamer. Allen Verschwörungstheoretikern zum Trotz sind die begrenzten Kapazitäten im Netz die Ursache: Die Nachfrage nach YouTube-Videos explodiert, deshalb werden wir die Kapazitäten jetzt verdreifachen. […] Qualitätsklassen, die diskriminierungsfrei angeboten werden, können die Refinanzierung auch auf die Anbieter der Inhalte verlagern. Für einige Services ist eben zu jeder Zeit eine bestimmte Qualität notwendig – so können Netzbetreiber Inhalte, die viel Netzkapazität benötigen, störungsfrei zu jeder Tageszeit zum Anschluss bringen. Anbieter können einwandfreie Services bieten, Kunden können sich auf Verfügbarkeit verlassen, Betreiber investieren in den Ausbau. […]

 
Die rosa Brille scheint festgewachsen, allerdings verwundert das natürlich im Blog der Telekom nicht besonders :-) Darum möchte ich den Absatz doch mal kurz sezieren:

  • Bemerkenswert ist ja die Aussage »deshalb werden wir die Kapazitäten jetzt verdreifachen« — wenn das so einfach geht, warum nicht früher, anstatt den Kunden Highspeednetz in der Werbung vorzugaukeln und ‘ne Wurfleitung faktisch anzubieten?
  • Die Bezahlung der Leistungen ist schon, mehrfach, erfolgt.
    • Es zahlt jeweils der Anbieter an seinen direkten Netzlieferanten.
    • Es zahlt jeder Endkunde für eine Regelbandbreite; der moderne Zusatz »bis zu« greift bei der technischen Anbindung der Last Mile, nicht aber für den Backbone und die Netzübergänge.
  • Natürlich gibt es für 19,95 im Monat keine garantierten 16 MBit/sec zu jedem einzelnen Rechner auf diesem Planeten. Aber: »Best Effort« ist es eben auch nicht, wenn man ein bestehendes und erkanntes Überlastproblem nicht behebt. Das wäre »Least Effort«, dafür wären auch 1,95/Monat zu viel.
  • »Die Refinanzierung auch auf die Anbieter der Inhalte verlagern« heißt nichts weiter, als auch was von dem Kuchen des direkten Providers abhaben zu wollen; um beim Telefon zu bleiben, dem traditionellen Geschäftsfeld der Telekom, um das erhöhte Gesprächsaufkommen durch unerwünschte Werbeanrufe schultern zu können nach dem Preisverfall in den letzten Jahrzehnten (von umgerechnet ca. 10 EUR/h Ferngespräch auf heute rd. 0,6 EUR/h — 60 Minuten zu je 1 Cent), muß jeder Telekom-Kunde nun pro angenommenem Anruf 5 Cent pro Minute zahlen? Denn die Callcenter zahlen ihren Carrier ja schon, für welchen Mehrwert sollten sie an die Telekom also noch zahlen? Bleibt als Melkvieh doch nur der eigene Kunde …

Letztlich argumentiert die Telekom hier ähnlich schräg wie die privaten TV-Anstalten beim HD+-Unsinn: für eine technisch überflüssige Verschlüsselung und Einschränkungen bei der Nutzung soll der Kunde, bitte schön, mehr zahlen, schließlich biete man ja auch einen Zusatznutzen — für die Anstalten (Werbeüberspringverbot, Verschlüsselung des zuvor unverschlüsselten Signals). Für den Kunden bedeutet HD+ nur Nachteil an Nachteil, es ist ein technisches Dongle zur Etablierung eines neuen Geschäftsmodells, welches man sich vom Nutzer bezahlen läßt.

Posted on

Imposanter Zug

(Blogged via flickr)

Ehemaliger DDR-Schnellzug, reingerollt und zur Besichtigung auf Gleis 8 freigegeben anlässlich des fuünfjährigen Bestehens des Berliner Hauptbahnhofes.

Kamera: Nokia N900 (Brennweite 5.2mm, f/2.8)

Posted on

Sekte und Warner auf'm Alex

(Blogged via flickr)

Panorama mit Android schlug fehl, drum kurze Bilderklärung: links ein Scientology-Stand, dem gegenüber rechts ein Trupp von 3, 4 jungen Menschen mit Masken und Warnschildern ‘gefährliche Sekte’ oder so (rechts, etwas aus der Bildmitte).

Kamera: Motorola Milestone (Brennweite 4.0mm (35mm equivalent: 30mm), f/2.8)

Posted on

Voll grün!

(Blogged via flickr)

Und jetzt in ‘nen mobilen Bioreaktor verklappt :-)

Kamera: Vignette Vignette for Android

Posted on

Amsel, Drossel, Telekom?

Dienstag vormittag erfuhr ich von dem Gerücht, die Telekom würde die Bandbreite zum YouTube-beherbergenden Netz nicht bedarfsgerecht aufstocken, weshalb YouTube von (DSL-) Anschlüssen des Rosa Riesen aus mehr häufiger denn nicht »unspaßig« sei.
Nun, wie schon geschrieben, falls dem so wäre – und im Jahre 2011 hätte ich derlei von einem so großen wie wichtigen Anbieter einfach nicht mehr erwartet – würde es ein Phänomen erklären, was schon zu 85% per Hardwareupgrade zu lösen beschlossen war: Auf dem Familien-/Wohnzimmer-Netbook, erste Generation, sei YouTube immer ein Geduldsspiel. Nun, ich habe dessen Minderperformance vor einem Jahr schon thematisiert — allerdings routete ich seinerzeit noch anders, sodaß das die fehlende Bandbreite bei der Telekom hier nicht zum Tragen gekommen sein dürfte.
Ein Problem bei YouTube ist natürlich die Meßmethode — wie mein alter Physik- und E-Technik-Pauker nicht müde wurde zu betonen: wer viel mißt, mißt Mist. Klick im Browser fällt also flach; das geht ohne Meßirritation auch nicht via Remote.
Aber zum Glück gibt es ja youtube-dl. Als Referenzmessung damit schon einmal der Download des Raabschen Auftritts beim ESC, hier aus Berlin (16 MBit/sec ADSL2-Link (13 MBit/sec derzeit nur noch lt. Fritzbox) von Alice, also Hansenet-/Telefónica-Backbone – allerdings geht das über einen OpenVPN-Tunnel nach Gütersloh, d. h. der Internetzugangsprovider hier ist mein PI im Telefónica-Netz):

wusel@berlin:~$ youtube-dl http://www.youtube.com/watch?v=grMLUCkbcrY
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 1.02M/s ETA 00:00

Da parallel die Doctor Who-Folge vom Samstag mit 2,5 MBit/sec aus Gütersloh auf meinen VDR hier in Berlin kopiert wurde, ist das wohl erst einmal recht nah am »Linespeed«. Vergleichsmessung mit bis auf Grundrauschen leerer Alice-Leitung: 

[download] 100.0% of 210.70M at 1.15M/s ETA 00:00

Also kein Einzelfall :-)
In Gütersloh nutze ich ein geteiltes Setup; interne und Geräte wie Telefone, Tablets, Windows arbeiten in einen RFC1918-Addressraum, der auf dem Router dann auf die T-VDSL-Public-IP genatttet wird. Linux-Laptops, Server u. dgl. haben eine Adresse aus meinen PI-Netzen, die über die T-VDSL-Anbindung ebenfalls ins RZ Gütersloh getunnelt und dort dann ins Netz geht — mit der Wirkung, daß ich zwar innerhalb Deutschlands das Telekom-Netz nutze (strenggenommen nur VDSL-GT bis Übergabepunkt zu Telefonica (dem Trace nach meistens Berlin oder Düsseldorf) und ab da dann schon nur noch Telefonica). Allerdings endet der VDSL-Tunnel im RZ noch auf einem Dual-P3 1,4 GHz in einer VM, die Anbindung Berlin terminiert auf einem 2,x GHz-Xeon-System, ohne VM-Overhead. Außerdem ich die Anbindung in GT mit einer Grundlast inbound von ca. 4-5 MBit belegt, die Werte müssen daher nicht zwingend soo viel besser sein als in Berlin :-)
Messung also aus Gütersloh, Internet-Übergang Telefonica: 

[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 889.08k/s ETA 00:00

Hernach habe ich 74.125.0.0/16, den Bereich, in dem sich derzeit YouTube-Server für mich befinden, auf das direkte NAT zur Telekom umgeroutet, mit diesem Ergebnis: 

GT_via_T-VDSL:~$ ./youtube-dl 'http://www.youtube.com/watch?v=grMLUCkbcrY'
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 272.53M at 784.04k/s ETA 00:00

Spannende Frage: warum ist die Datei für T-Kunden größer als für den Rest? Und warum bei der Vergleichsmessung über Telekom wieder nicht mehr‽ 

GT_via_T-VDSL:~$ ./youtube-dl 'http://www.youtube.com/watch?v=grMLUCkbcrY'
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 682.19k/s ETA 00:00

Um zu zeigen, daß hier wirklich auf die Anbindungsgeschwindigkeit abgestellt wird, ein Test direkt von einem mit 100 MBit/sec angebundem Server: 

[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 7.35M/s ETA 00:00

Und GBit sieht so aus: 

[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 22.15M/s ETA 00:00

Hier schlägt übrigens auch die Anbindung nach Berlin auf.
Da dies lastabhängig ist und gegen Mitternacht das Gros der T-Kunden schon schlummern dürfte, werde ich das mal tagsüber verifizieren …
Ein anderer lustiger Aspekt: per Proxy geht’s besser als direkt: 

GT_via_T-VDSL:~$ http_proxy=http://www-proxy.t-online.de ./youtube-dl 'http://www.youtube.com/watch?v=grMLUCkbcrY'
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 1.29M/s ETA 00:00

Im Vergleich zu …

GT_via_T-VDSL:~$ ./youtube-dl 'http://www.youtube.com/watch?v=grMLUCkbcrY'
[youtube] Setting language
[youtube] grMLUCkbcrY: Downloading video webpage
[youtube] grMLUCkbcrY: Downloading video info webpage
[youtube] grMLUCkbcrY: Extracting video information
[download] Destination: grMLUCkbcrY.mp4
[download] 100.0% of 210.70M at 819.63k/s ETA 00:00
Posted on

Weltuntergang!!!11!

Spiegel Online hat grade schier unglaubliches festgestellt: zu bekannten Accesspoints baut Android automatisch eine Verbindung auf.
Ich weiß ja nicht, was sie getrunken haben, aber: das montierte Verhalten ist auch so Usus, wenn man sich an verschlüsselten Access Points anmeldet. Zwar ist der Verkehr zwischen Androiden und AP dann verschlüsselt, aber im Spiegel-Artikel übernimmt der Angreifer ja den Accesspoint. Und dagegen hilft dann nur noch End-zu-End-Verschlüsselung…

Posted on

Da schau her, Telekom drosselt YouTube?

(Vorweg, dieser Cursor bei Android 2.3 ist eine verdammte gute Erfindung!)
So, per Twitter wurde ich über einen Beitrag von @caschy aufmerksam und kommentierte wie folgt:

Oh, das ist mal spannend und erklärt ein Phänomen zu Hause: meine Frau klagte jüngst über rottige YouTube-Performance auf ihrem Atom-Netbook. Ich konnte das nicht nachvollziehen, da anderer Flash-Kram gut läuft und bei mir unter Linux auch YouTube. Aber jetzt fallen die Schuppen tonnenweise aus den Haaren: das Windows-Netbook hängt im 1918er Subnetz, das direkt auf Telekom-VDSL genattet wird; mein Linux-Krempel hängt im Netz mit PI-Adressen, welches über Telefonica geroutet wird. Danke für den Hinweis, das wird später mal umgeroutet und dann mal hören, ob’s nun besser tubet …

 
Ich werde hier weiter berichten …