Grenzen und Herausforderungen des Internets Prof. Anja Feldmann, Ph.D. TU-Berlin Deutsche Telekom Laboratories
Das Internet 2
Das Internet : Was ist es Soziales Phänomen Mehr als ¾ aller Deutschen nutzen das Internet Das Internet wird subjektiv als Informationsquelle empfunden Cyberspace Ändert Kommunikationswege und -arten Mensch zu Mensch Computer zu Computer. Veränderte Geschäftsgrundlagen und Erwartungen Just in time. 3
Das Future Internet? Informations- und Mediengesellschaft Jeder generiert Inhalte Sensoren und Kameras überall Neue Verteilformen Neue Inhalte und Interaktionsformen Herausforderungen Verifikation Fusioniern/filtern von Information Situations-angepasst Anreize, Vertrauen, Privatsphäre 4
Internet Herausforderungen Die Only einzige constant Konstante in the im Internet ist der Change Wechsel 5
Verkehrs Charakterisierung
Verkehrsmix? 7
Verkehrsmix Heute? 8
HTTP Usage Warum ist HTTP so populär (wieder)? Bietet HTTP populäre, hochvolumige Inhalte? Wird HTTP als Transportprotokol für andere Anwendungen genutzt? Populäre content-types nach volume flash-video 25.2% RAR 14.7% image 11.5% video 7.6% other 23.4% Flash-Video clearly dominates unclass. 17.6% 0 20 40 60 80 100 Domain Popularität: One-click-hoster top domain: 15% der HTTP Bytes Gefolgt von Video Portalen (mit flash-video) HTTP Dominanz: Populäre, hochvolumige Inhalte 9
Was macht das Internet so sexy Anwendungen können von jedem verbreitet werden, der im Netz ist. (Gegensätzlich zur Situation in der Telefonie.) Mehr-Dienst Netz: Alles über das Internet Jedes Anwendungsprotokoll über IP IP über jede Netztechnologie 10
Heutiges Internet ausser Form!!! Daten-Ebene Kontroll-Ebene Picture due to Rui Aguilar Redesign nötig? 11
Heutiges Internet: Architektur basierte Grenzen Vertrauensannahmen Internet basiert auf Kooperation Konkurrenz Ursprüngliche Internet kannte keine kommerziellen Betrachtungen Kanten Vielfältigkeit Host-zentriert ignoriert Mobilität, Sensoren, etc Netzbasierte Dienste Ursprüngliche Internet gibt kaum Informationen frei Beschränkt neue Dienste Beschränkt das Netzmanagement Fast keine Veränderungen im Kernnetz 12
Redesign des Internets? Entwerfen alternativer Architekturen Ansätze Inkrementell Punktuelle Verbesserungen der jetzigen Architektur Clean slate design (CSD) Von vorne anfangen Vorteile CSD Nichts ist unmöglich: ermöglicht neue Ansätze in der Netz- und in der Dienstarchitektur Ausprobieren alternativer Architekturen Architektur ist nicht festgelegt Experimente und Rückschläge sind möglich 13
Infrastruktur Speicher Processing Herausforderungen: Netz als Verarbeitungs /Speichereinheit CloudNetze Netzvirtualizierung Netz Enabler 14
Nutzer Nutzermodell Daten/Informationen Fusion Notwendig: Zugang Adressierung CloudNetze (dynamisch!) Netzprotokolle Network 15
Ermöglichen von alternativen Architekturen Virtualisierung CloudNets
Virtualisierung: Was meine ich? Abstraktionskonzept Verbirgt die Details der Hardware Bietet eine Ebene der Indirektion Virtualisierung bietet Isolation & Separierung Ressourcenteilung Wiederbenutzung Abschalten Erfolge Virtual memory Virtual servers Cloud services 17
Virtuelle Netze: Szenarien Unterschiedliche Architekturen/Protokolle pro CloudNetz Muss nicht das IP Protokoll sein Mehrere parallele Netze == Diversität Zugang zu den Netzkomponenten für die Anwendungen/Dienste Lösung für den Internet Impasse (Sackgasse) Kombiniert Clouds mit Netzen Neue Dienstideen Dynamisch Neue werden kommen und Alte gehen Migration / Expansion / Kontraktion Effizienzgewinn und neue Managementmöglichkeiten Entworfen für Veränderung 18
Warum jetzt? Hardware Unterstützung Server, Router, Switche, Signifikante Ressourcen im Netz Schnelle Paketweiterleitungshardware verfügbar, z.b.: OpenFlow Realität Z.B.: DSL Zugang Überdenken des network + information management! Internet Probleme: Verfügbarkeit und Verlässlichkeit Sicherheit Skalierbarkeit und Diversität Unterstützung neuer Anwendungen Geschäftsmodelle 20
Netzvirtualisierung: Vision Infrastructure Virtualized Substrate Virtualization of Resources (partitioning of physical infrastructure into slices ) Provisioning of Virtual Networks (on - demand instantiation of virtual networks) Virtual Network Virtual Network Virtualization Management 21
Grundlage neue Technologien Beispiel: OpenFlow Tolle Technologie für die Separierung von Hard- und Software
Schnelles 101 Klassischer Switch 23
Schnelles 101 FLOW_MOD entry PKT_IN OpenFlow Switch 24
OpenFlow Einträge (Siehe Openflow Intro Präsentation von N. McKeown) 25
Warum? Klassischer Switch: Cisco 3548XL 26
Warum? Control software (Management, STP, Basic VTP, etc. ) Control Hardware: Embedded PC Dataplane: Interfaces, TCAM, Switch fabric Klassischer Switch: Cisco 3548XL Eine black box 27
Warum? Operator says: Vendor answer: But I need extended VTP / a 3rd spanport etc.! Buy one of these! 28
Warum? Operator says: Vendor answer: I need something better than STP for my Datacenter... We don't have that! 29
Warum? Ernsthafter: Geschlossene HW/SW behindert Innovation Forscher können wenig ausprobieren, insbesondere at scale (nein, NetFPGA kann nicht für Skalierbarkeit genutzt werden) Datencenterbetreiber können nicht ihr spezifisches Netzprotokoll entwerfen und betreiben 30
Software Defined Networking Nutzung von (open source) Software anstelle spezialer Hardware! 31
Software Defined Networking Case Study 1 OFRewind: Aufzeichnen und Abspielen des Netzwerkgeschehens zur Fehlersuche in Netzen 32
Software Defined Networking Case Study 2: OpenFlow basierter Router Nutzung der Möglickeiten von + OpenSource Routing Software + preisgünstiger Switch-Hardware 33
OpenFlow basierter Router: FIBIUM FIBIUM Nutzt das OpenFlow Interface des Switch: RouteVisor programiert den Switch Route Cache Management ermög-licht hohe FastPath- Performanz trot beschränkter Hardware RouteVisor Präsentiert die Switch/PC Kombination nach außen als Router Interface zwischen Route Kontroll-logik auf dem PC und dem Switch Sammelt Verkehrsdaten und optimiert somit den Fast- Path 34
Warum Software Defined Networking? Hardware als Beschleuniger für Softwarelösungen Software Schneller und einfacher zu ändern und verbessern Software Engineering Tools und Konzepte können genutzt werden Einfacher Features zu kombinieren Einfacher Informationen zu exportieren Einfacher zu virtualisieren Kann Veränderbarkeit erleichtern/sicherstellen! 35
Verkehrsmanagement Inhalte-basiertes Verkehrsmanagement Ausnutzung von DNS als Indirektionsmechanismus (DNS Softwarelösung)
Struktur des Internets Source: Arbor Networks 2009 37
Jetzige Struktur Google, Akamai, RapidShare, Source: Arbor Networks 2009 Neuer Kern von miteinander verbundene Inhalte- und Verbaucher-Netzen 38
Herausforderung Wer kontrolliert wie den Internet-Verkehrsfluss? Die ISPs? Die Benutzer? Die Inhalteanbieter? Kostenstrukturen ISPs CAPEX/OPEX Netz (Strom) Volumen- und distanz-abhängig Inhalteanbieter CAPEX/OPEX Server (Strom) Zugangsgebühren Inhalte 39
Herausforderung (2) Wer kontrolliert wie den Internet-Verkehrsfluss? Die ISPs? Die Benutzer? Die Inhalteanbieter? Einkommensstrukturen? Benutzer zahlen ISPs für Zugang Oft volumen-unabhängig Distanz-unabhängig ISPs zahlen an ISPs für Zugang Volumen abhängig Distanz unabhängig Benutzer zahlen Inhalteanbieter für gewisse Dienste Inhalteanbieter <-> ISP??? 40
Verkehrsflusssteuerung via DNS 5 External DNS 2 1 3 Provid er DNS Internet Service Provider (ISP) 4 Client Servers 41
Verkehrsflusssteuerung via DNS (2) Warum? Viele Inhalte im Web Einzelner Server kann nicht alle Inhalte liefern Braucht eine verteilte Infrastruktur Häufig mittels eines Content Distribution Networks (CDNs) DNS: Einfacher, schneller Mechanismus Auswahl basiert auf IP Adresse, und somit Ort, des DNS Servers Optimierungskriterien Last und Kosten auf den Servern Performanz für den Nutzer 42
Downloadzeiten Beispiel: CDN Zum Teil suboptimale Downloadzeiten! 43
Verkehrsflusssteuerung Source: Arbor Networks 2009 Neuer Kern von verbundene Inhalte- und Verbaucher-Netzen ISPs haben die Kontrolle verloren 44
Inhalte-basiertes Verkehrsmanagement
Traditionelles Verkehrsmanagement Verkehrmanagement: Adjustieren des Routings/ Peerings, Netzausbau Offline Prozess Source: Arbor Networks 2009 46
Kernbeobachtungen Motivation Viele Inhalte im Web Einzelner Server kann nicht alle Inhalte liefern Braucht eine verteilte Infrastruktur Häufig mittels eines Content Distribution Networks (CDNs) Komponenten eines CDNs Spiegel des Originalservers Caches, die die Inhalte nach Bedarf replizieren Lastbalanzierungsmechanismus 47
Inhalte-basiertes Verkehrsmanagement Verkehrmanagement: Durch Mitauswahl der Server Source: Arbor Networks 2009 Online Prozess 48
Lastbalanzierung durch Serverwahl Host B Host A Host C Client 49
Lastbalanzierung durch Serverwahl Host B Host A Host C Client 50
Lastbalanzierung durch Serverwahl Host B Host A Host C Client 51
Serverwahl: Wie? External DNS 1 2 6 3 Provid er DNS Internet Service Provider 5 (ISP) 4 PaDIS Client Host Provider-aided Distance Information System 52
Inhalte basiertes Verkehrsmanagement Rebalanzierung des Verkehrs auf weniger überlastet 50% 0.5% 5% Link Utilization Top-10 Inhalteanbieter Reduktion der Maximallast bis zu 30% 5-10% Reduktion des Gesamtverkehrs Erhöhung der Verkehrslokalität des HTTP Verkehrs von 25% 50% 53
Lessons learned Open interface == Neue Möglichkeiten Flexibilität von Software siegt über geschlossene Systeme Beispiel: FIBIUM Zukunft Kontrol-Ebene: Open source routing software Daten-Pfad: Hardware Software Defined Networking Internet Kontrol- und Managementsoftware CloudNetze Neue parallele Netzwerkarchitekturen
Only constant in the Internet Be ready Change design for change! 56