Das End-to-End-Argument

Transkript

1 Das End-to-End-Argument Eine kritische Betrachtung des End-to-End-Arguments im Bezug auf das Internet Einleitung Matthias Bärwolff, Oktober 2004 Digitale Kommunikations-Netzwerke unterscheidet sich von Kuriernetzwerken und Netzwerken wie dem Straßenverkehr oder der Post in einem entscheidendem Punkt. Die Kosten und die benötigte Zeit, um Daten von einem Ende zu einem anderen Ende zu transportieren sind vergleichsweise gering, was zu einer neuen Qualität von Kommunikation führt. Denn die Kosten und der Zeitaufwand, um Daten in einem elektronischem Netzwerk mehrfach zu verschicken, weil sie beispielsweise auf dem Weg durch das Netzwerk verloren gehen oder verfälscht werden, ist deutlich weniger signifikant als bei langsameren, mehr oder weniger manuellen Netzwerken in denen Dinge transportiert werden. Ein Postpacket mit wertvollem Inhalt ist bei Verlust während des Transports eventuell nicht mehr ersetzbar, in jedem Falle ist der Gegenwert des Geldes den man ansetzen mag unwiederbringlich verloren. Im Straßenverkehr geht es bei den vorhandenen Regeln und deren Durchsetzung gar um die Verhinderung von Unfällen, deren Schaden irreparabel sein kann. In elektronomischen Netzwerken hingegen sind die Kosten einer wiederholten Versendung von Daten im Allgemeinen praktisch vernachlässigbar. Und da, siehe Post oder Straßenverkehr, Regeln und Funktionen innerhalb des Netzwerks niemals vollständig sein können, kann man in elektronischen Netzwerken auf bestimmte Funktionen innerhalb des Netzwerks verzichten. Gewisse Funktionen liegen beim Post-Netzwerk oder dem Straßenverkehrs-Netzwerk also aus dem einfachen Grunde im Netzwerk, weil die Enden sie nicht implementieren können. Beispielsweise kann ein Verlust von übertragenen Dingen durch die Enden des Netzwerks nicht ohne Weiteres behoben werden. Bei elektronischen Netzwerken in denen digitale Kopien transportiert werde liegt die Sache jedoch anders. Damit stellt sich der Kompromiss zwischen den Kosten einer Implementierung von Funktionen im Netzwerk und deren Nutzen für die Enden der Kommunikation in einem neuen Lichte. Es kann hier billiger und effizienter sein, gewisse Funktionen, wie beispielsweise Fehlerkontrolle, überhaupt nicht im Netzwerk zu implementieren, sondern durch die Enden umzusetzen. Zumal die Implementation von Funktionen wie beispielsweise fehlerlose Übertragung innerhalb eines Netzwerks - siehe Post oder Straßenverkehr - niemals vollständig sein können. Wenn also Fehler bei der Kommunikation auftreten, verschicken die Enden die Daten einfach nochmal, bis eine positive Rückmeldung des Empfängers vorliegt. Dieses Argument wird seit dem bahnbrechenden Artikel von Saltzer, Reed und Clark (1984) Endto-end arguments in system design End-to-End-Argument genannt. In diesem Artikel wurden erstmals die technische und ökomonischen Argumente vorgebracht für die Sinnhaftigkeit der Platzierung von Funktionen eines Netzwerkes an dessen Enden. Die Autoren argumentieren, dass es am sinnvollsten ist, im Netzwerk keine Funktionen zu implementieren, die auch an den Enden implementiert werden können und die eben deren Partizipation benötigen, z.b. sicherer und vollständiger Dateitransfer. Funktionen sollten nur aus Gründen der Performance durch das Netzwerk bereitgestellt werden, und auch dann nur, wenn sie von allen angeschlossenen Hosts und Diensten benötigt werden. Das bedeutet, dass sämtliche Funktionen, wie Fehlerkontrolle, Fehlerkorrektur, Flusskontrolle, Verschlüsselung und Kompression an den Enden implementiert werden sollten. Das End-to-End-Argument Das Hauptargument von Saltzer, Reed und Clark (1984) für die Implementation von Funktionen an

2 den Enden der Kommunikation, und nicht bei den Netzwerk-Knoten, liegt darin, dass nur die Enden eine Funktion vollständig und korrekt implementien können, da sie niemals vollständig sicher sein können, dass die Zwischenstationen die Funktion in ihrem Sinne ausführen. Das typische Beispiel, das auch die Autoren heranziehen, ist das eines Dateitransfers zwischen zwei Hosts durch ein Netzwerk. Die Enden können eben nur dann vollständig sicher sein, dass eine Datei vollständig und unverändert übertragen wurde, wenn sie sich dessen selbst durch eine Fehlerkontrolle versichern. Wenn nun außerdem Knoten im Netzwerk solche Fehlerkontrollen implementieren, wäre diese Funktion redundant und damit der Performance des Netzwerks abträglich, insbesondere wenn eine solche Fehlerkontrolle und -korrektur nicht von allen ans Netzwerk angeschlossenen Hosts benötigt wird. Ein weiterer entscheidender Vorteil von End-to-End-Netzwerken liegt für die Autoren in der damit gewonnen Flexibilität des Netzwerkes: [A] lower layer of a system should support the widest possible variety of services and functions so as to permit applications that cannot be anticipated. Abbildung 1: Weg von Daten durch ein Netzwrerk über einen Router Mit dem Internet ist das Argument für End-to-End-Implementierung von Netzwerkfunktionen zu einer äußerst populären und mächtige Richtlinie für das Design von Netzwerken geworden. Das Internet ist das wohl prominenteste Beispiel für ein Netzwerk, das weitgehend End-to-End aufgebaut ist. Im Nachhinein mag die Designentscheidung trivial erscheinen, in den 1970er Jahren war sie es nicht (Reed 2000). Man hätte Funktionen, die auf der Transportschicht (transport layer) liegen ohne weiteres in die Netzwerkschicht (network layer) schieben können. Doch man beschränkte die Rolle des IP Protokolls, den Designprinzipien des später so kodifizierten End-to- End-Arguments folgend, auf den unbestätigten verbindungslosen Transport von Datagrammen. Alle anderen Funktionen, wie Flusskontrolle, Fehlerkontrolle, etc. liegen beim Internet an den Enden, bei den angeschlossenen Hosts. Praktisch die einzige Funktion, die aus Gründen der Robustheit im Netzwerk ausgeführt wird, ist die des Routings. Die Geschichte des Internets war dann auch der Siegeszug des End-to-End-Arguments, das für viele Beobachter die unabdingbare Voraussetzung für Freiheit und Innovation des Internets darstellte. Man beachte jedoch den qualitativen Sprung bei der Interpretation des End-to-End-Arguments. Zunächst nicht viel mehr als ein Argument für die technische Sinnhaftigkeit der Platzierung von Kommunikationsfunktionen an den Enden der Kommunikation ist das End-to-End-Argument heute fast zu einer Zauberformel gegen die Bedrohungen des Internets durch kommerzielle und staatliche Interessen geworden. Autoren wie Lessig machten insbesondere Innovationskraft, Freiheit und Privatsphäre der Nutzer als Charakteristika des Internets aus, die auf dem End-to-End-Design des Internets basieren. Die derzeitige Diskussion ist also kaum mehr nur technischer, sondern politischer Natur, was nicht verwundert, ist doch Kommunikation im Internet ein primär sozialer Prozess. Computer sind hier ja letztlich nur Agenten für Menschen, die die eigentlichen Enden der

3 Kommunikation darstellen. In Gange gekommen ist die Diskussion um die Vorteile der End-to-End-Struktur des Internets primär durch Entwicklungen der letzten Jahre, bei denen End-to-End-Prinzipien verletzt wurden: Firewalls, Caches, Active Networks, NAT, Multicasting und QoS. Manche Kommentatoren sehen mit Webservices verstärkt neue Mittlerfunktionen, wie Verschlüsselung, Autorisierung, Zugangskontrolle, Überwachung, Abrechnung, entstehen. 1 Dabei kommen verstärkt intelligente Zwischenstationen wie z.b. Application Level Gateways zum Einsatz, die im Protokoll-Stack bis ganz nach oben wandern und darauf Funktionen ausüben. 2 All diese Veränderungen an der ursprünglichen Struktur des Internets stellen das End-to-End-Argument letztlich in Frage. Es sollte jedoch nicht vergessen werden, dass schon Saltzer, Reed und Clark (1984) den unvermeidlichen Zielkonflikt zwischen Skalierbarkeit, Offenheit und Anwendungs-Neutralität und Performance sahen. Insbesondere weisen sie darauf hin, dass die Identifizierung der Enden eine zentrale und nicht immer triviale Aufgabe beim Design von End-to-End-Systemen ist. Kritik am End-to-End-Argument Abbildung 2: Bedrohungen des End-to-End-Designs Wenn auch das Hauptargument für das End-to-End-Design von Netzwerken kaum etwas von seiner Eleganz verloren hat, so gibt es doch einige ernst zu nehmende Kritikpunkte an dessen Stringenz. So sind beispielsweise nicht immer die menschlichen Anwender oder deren unmittelbare Agenten, die Anwendungen, die konkreten Enden bei einigen der verbreitetsten Kommunikations-Szenarien im Internet. , beispielsweise, ist eine Anwendung, die asynchrone Kommunikation erlaubt, wobei die Daten auf Zwischenstationen gespeichert werden. Dabei werden Daten mit TCP auf den Mailserver übertragen. Man könnte nun, als strenger Verfechter des End-to-End-Prinzips, darauf verweisen, dass die Mailserver garnicht die Enden der Kommunikation sind, sondern die Postfachbesitzer und die Mailserver daher redundante Funktionen implementieren, die gegen End-to-End-Prinzipien verstoßen. 3 In der Tat sind die wenigsten Kommunikationsanwendungen im Internet streng nach dem End-to-End-Prinzip gestaltet. Es ist nämlich nicht so, dass die Transportschicht (z.b. TCP) den Endpunkt für Applikationen wie Datentransfer darstellt, sondern die Applikation selbst. Beim Schreiben der Daten auf lokale Datenträger kann es zu Fehlern 1 Siehe z.b. Cutting the Middleman Back in - Intermediaries will thrive in the Web services world, < 2 Es gibt zudem Vermittler im Internet, die eben durch die Funktion des Vermittelns Enden zusammen bringen, z.b. Suchmaschinen, Auktionshäuser oder elektronische Marktplätze. Hier kommt End-to-End-Kommunikation entweder durch oder über solche Vermittler überhaupt erst zustande. Man könnte diese Vermittler allerdings auch als Enden begreifen, die andere Enden zusammen bringen. 3 Teilweise implementieren Mailserver gar Funktionen, wie Spam-Filtering, treffen also Entscheidungen an Hand des Inhalts einer End-to-End-Kommunikation. Solche Funktionen verstoßen natürlich eklatant gegen das End-to-End- Prinzip.

4 kommen, die die Transportschicht nicht beheben kann. Also müssten dem End-to-End-Argument zu Folge Applikationen die genannte Funktion implementieren, was im Allgemeinen jedoch selten geschieht, weil der Nutzen einer solchen Integritätskontrolle vergleichsweise gering ist. Zudem setzt das Testen vollständiger Integrität durch eine Applikation die vollständige Fehlerlosigkeit der Applikation selbst voraus, was im Allgemeinen nicht trivial zu beweisen ist. Die allermeisten Kommunikations-Anwendungen verlassen sich also einfach auf die Funktionen, die durch die Transportschicht bereitgestellt werden (Moors 2000). Zudem stellt Moors die technische Korrektheit des zentralen End-to-End-Arguments in Frage. Das End-to-End-Argument basiert auf der kritischen Annahme, dass die Endpunkte der Kommunikation Funktionen wie Integritätstests besser implementieren können als die Netzwerk-Knoten, nämlich completely and correctly. Es ist jedoch zum Einen, wie Moors ausführt, auf Grund der wahrscheinlichkeitstheoretischen Natur von Integritätstests (z.b. CRC) praktisch unmöglich, vollständige Integrität von übertragenen Daten zu gewährleisten. Die Entscheidung, zuverlässigen Datentransfer durch die Transportschicht zu gewährleisten, (und TCP ist das am meisten genutzte Protokoll auf der Transportschicht) ist, so Moors, nicht durch das End-to-End-Argument begründet, sondern primär eine Sache von Vertrauen. Die eigentlichen Enden der Kommunikation delegieren also Aufgaben, die Ihnen in einem vollständigen End-to-End- Design zufallen würden, aus Gründen der Effizienz tiefer ins Netzwerk. Tatsächlich ist es technisch durchaus sinnvoll, Funktionen wie Fehlerkontrolle, Flusskontrolle und Multicasting ins Netzwerk zu verschieben, um effizient mit den vorhandenen Netzwerk-Resourcen umzugehen. Moors merkt an, dass diese Funktionen schlicht ins Netzwerk gehören, das Netzwerk also für deren Durchführung verantwortlich ist. Dies liegt unter anderem darin begründet, dass, eben so wie die Enden nicht vollständig dem Netzwerk vertrauen können, das Netzwerk den Enden nicht unbedingt vertrauen kann. Dieser Einwand ist wohl der gewichtigste der gegen das End-to- End-Argument angeführt werden kann. Moors führt diesen Einwand im Bezug auf Netzwerk- Überlastungs-Kontrolle an: [T]he network... has no reason to trust that endpoints will cooperate in controlling congestion. Sheldon (2001, S. 246) bemerkt treffend: While connectionless networks have advantages, quality of service is not one of them. Die Enden der Kommunikation im Internet kümmern sich sozusagen nur um sich selbst, implementieren also Flusskontrolle über TCP. Dabei geht es aber nicht primär darum, Verstopfung des Netzwerks zu vermeiden, sondern lediglich darum, den Empfänger nicht zu überfordern. Eine wirksame Verstopfungskontrolle ist eben nur durch Mitwirkung des Netzwerkes zu erreichen. Da das IP-Protokoll aber keine Verstopfungskontrolle oder QOS kennt, musste das Netzwerk dann auch entsprechend obskur auf Überforderungen durch Endpunkte reagieren: Die erste Verstopfungskontrolle und -vermeidung basierte darauf, dass Netzwerk-Knoten bei höher werdender Last Packete verwarfen, um TCP zur Verringerrung der Bandbreite zu bewegen. Ein heute häufig verwendeter Mechanismus ist Random Early Discard (RED). Eine weitere Strategie ist mittlerweile im TCP Protokoll integriert: Slow Start Congestion Control. Dabei steigert sich die Datenübertragungsrate des Senders langsam, um die Kapazität des Netzwerkes vorsichtig zu prüfen. Man bemerke, dass sich diese Strategie sich jedoch nur auf TCP bezieht, nicht auf UDP oder andere, durch die Enden beliebige verwendbare Protokolle. Außerdem ist für Anwendungen wie voice over IP die damit einhergehende Verzögerung der Verbindung kaum hinzunehmen, was dazu führt, dass die Slow-Start-Doktrin von den Enden zunehmend ignoriert wird. Ein weiteres Beispiel für den Konflikt von End-to-End-Prinzip und den Unvermeidlichkeiten in einem offenen Netzwerk ist Sicherheit. Hier kommt wieder das Vertrauensproblem ins Spiel. Kaum jemand wird dem Nutzen von Firewalls zum Schutz besipielsweise von Firmen- oder Universitätsnetzen widersprechen. Dabei verletzen diese aber unter Umständen das End-to-End- Prinzip, indem sie Packete, z.b. nach deren Herkunft oder Inhalten untersuchen. Wenn nun die Packete aber beispielsweise verschlüsselt sind, werden diese vom Firewall verworfen, weil er sie nicht analysieren kann. Das verstößt zwar gegen End-to-End-Prinzipien, da aber der Systemadministrator im Zweifel eher an seine eigenen Fähigkeiten, denn an die der an das

5 Firmennetzwerk angeschlossenen Personen glaubt (geschweige denn den Enden außerhalb des Firmen-Netwerks), wird er die Firewall-Variante möglichen End-to-End-Lösungen vorziehen. Auch hier ist der Ursprung des Problems wieder die Existenz von nicht vertrauenswürdigen Enden denen man am sinnvollsten auf der Ebene des Netzwerks begegnet, eben weil die Enden alle erdenklichen Freiheiten haben. Analog erklärt sich der Einsatz von Spam-Filtern auf Mailservern. Hier werden aus Gründen der Sicherheit und der Einfachheit für die Nutzer suspekte Mails aussortiert und gar nicht erst zugestellt, wobei es natürlich auch Seiteneffekte geben kann. Innovationen durch End-to-End? Neben technischen Argumenten gab es für Saltzer, Reed und Clark (1984) noch ein weiteres wichtiges Argument für das End-to-End-Prinzip, nämlich dass ein nach diesem Prinzip gestaltetes Netzwerk die beste Grundlage für unvorhersehbare künftige Anwendungen ist. Dieses Argument ist jedoch nicht vollständig schlüssig. Es mag zwar sein, dass Basisfunktionalitäten ein höheres Innovationspotential nach sich ziehen, es ist jedoch praktisch unmöglich, zu entscheiden, welche konkreten Basisfunktionen eine größtmögliche Vielfalt an Applikationen gewährleisten. So bemerkt Sandvig (2003): It is easy to build things that are made from blocks or functions that are present. If the service you want to build cannot be built from these functions, an end-to-end design strategy will not make your new idea easier to build. Die Existenz bestimmter Bausteine kann also im ungünstigsten Falle sogar bestimmte Innovationen verhindern, weil sie den Bau anderer Basisbausteine, wie beispielsweise QoS, nicht erlauben. Sandvig (2003) widmet sich in seinem Artikel stärker dem sozialen Aspekt der aktuellen Diskussion um End-to-End und stellt treffend fest, dass es im Kern nicht um Technik, sondern um Kontrolle und die Freiheit der Enden von der Einmischung dritter Parteien geht. So mag es zwar technisch sinnvoll und effizient sein, Funktionen wie Flusskontrolle, Caching oder Firewalls ins Netzwerk zu verlagern, es eröffnet jedoch die Möglichkeit für Dritte, Kontrolle über die Netzwerk-Enden auszuüben. 4 Das End-to-End-Design hat demnach eine wichtige nicht-techische Dimension: [E]ndto-end was initially chosen as a technical principle. But it didn't take long before another aspect of end-to-end became obvious : It enforced a kind of competitive neutrality. The network did not discriminate against new applications or content because it was incapable of doing so (Lessig 2000). Das Problem bei diesem qualitativen Sprung der Diskussion ist jedoch, dass hier eine normative Debatte um Freiheit und Innovation mit technischen Argumenten geführt wird: The best outcome that normative claims premised on the end-to-end argument can offer us is to produce the right results for the wrong reasons, but we might be even better at promoting innovation if we act for the right reasons. (Sandvig 2003). Und weiter führt er aus: History teaches us that the Internet had always had intermediaries, but that end-to-end proponents were happiest with the intermediaries that they knew (e.g., service providers initially universities). The end-to-end argument is a way to stop the new intermediaries by arguing that they are technically incorrect. Die Debatte über aktuelle Entwicklungen im Internet, die dem End-to-End-Prinzip widersprechen, sollte sich also nicht nur auf End-to-End-Argumente konzentrieren, sondern vielmehr auf Transparenz, Partizipation und Flexibilität. Dies würde denn auch eher der sozialen Dimension der Debatte entsprechen, insbesondere den Aspekten Kontrolle, Vertrauen, Verantwortlichkeit und Freiheit. Dieser Gedanke lässt sich beispielsweise auf die oben erwähnten Spam-Filter auf Mailservern anwenden. Hier ist es durchaus im Sinne der Anwender, dass entgegen dem End-to- End-Argument Mails herausgefiltert werden, deren Absender unbekannt ist oder die über bekannte Spam-Hosts versendet wurden. Jedoch muss der Vorgang zugleich transparent sein und dem Nutzer eine Anpassung der Filtereinstellungen erlauben. Er sollte also selbst wählen können, bis zu welchem Grade er dem Mailserver vertraut und Funktionen ins Netzwerk delegiert, die er auch am Ende implementieren könnte. 4 Unter < findet sich eine Studie des Berkman Center for Internet & Society zum Thema Internet Filtering. So machen beispielsweise Saudi Arabien und China extensiv von Filtern gebrauch.

6 Sicher ist es normativ vollkommen gerechtfertigt, für Freiheit und Innovationspotential einzutreten, letztlich geht es jedoch darum, einen Rahmen für regulative ordnende Eingriffe zu schaffen, der frei von Dogmatik ist. Die Diskussion um die zukünftige Struktur des Internets, die Machtverteilung und strukturell angelegte Freiheit der Enden ist ohne Frage wichtig. Und auch steht außer Frage, dass die Kommunikation im Internet von einer neuen Quallität ist. Jedoch hilft ein Blick in die Vergangenheit, um zu zeigen, dass nicht jedes Netzwerk mit innewohnender Intelligenz ein per se schlechtes und fortschrittsfeindliches Netzwerk ist. Man denke beispielsweise an das eingangs erwähnte Beispiel des Straßenverkehrs auf öffentlichen Straßen, der durch ein enormes Regelwerk reguliert wird. Dabei kommen sowohl normative Kontrolle durch Ampeln zum Einsatz, wie auch die Durchsetzung von Regeln durch die Polizei als Agent des Staates. Nicht jeder darf öffentliche Straßen nutzen, man benötigt eine Fahrerlaubnis, ein zugelassenes und verkehrstaugliches Fahrzeug, und trotzdem wird hier Mehrwert, auch unvorhergesehener produziert. Man darf praktisch alles transportieren, wohin man will. Auch Dinge, die es vorher noch nicht gab. In der Tat könnte man sagen, dass es eben erst diese Regeln, die durch das Netzwerk vorgegeben werden, sind, die überhaupt einen Verkehr ermöglichen, indem sie Verstopfung kontrollieren. 5 Ein weiteres Beispiel ist die Post. Auch hier darf jeder alles überallhin verschicken. Auch hier ist Platz für Innovationen. Also die Nutzung des Netzwerkes für vormals unvorhergesehene Zwecke, z.b. gewerblichen Handel über Ebay. Das Argument also, dass Innovation im Internet unabdingbar mit dem End-to-End-Design verbunden ist, ist noch vergleichsweise ungesichert. Noch ein abschließender Kommentar: Vielleicht sollte man eher darüber nachdenken, ob man intelligente Dienste neben rudimentären Diensten im Netzwerk implementieren kann. Also z.b. QOS für die die es brauchen, kein QoS für die die es nicht brauchen. Literatur/Quellen J. Saltzer, D. Reed and D. Clark (1984), End-to-End Arguments in System Designs, ACM Trans. Comp. Sys., 2(4), , Nov D. Reed (2000), The End of the End-to-End Argument, L. Lessig (2000), Innovation, regulation, and the Internet. The American Prospect, 11(10). T. Moors (2000), A critical review of End-to-end arguments in system design, T. Sheldon (2001), Encyclopedia of Networking & Telecommunications, Osborne/McGraw-Hill, New York. C. Sandvig (2003) (forthcoming). Shaping Infrastructure and Innovation on the Internet: The Endto-End Network that isn't. In D. Guston & D. Sarewitz (eds.), Shaping Science and Technology Policy: The Next Generation of Research. Madison: University of Wisconsin Press. Communication_Infrastructure_and_Innovation.pdf 5 Daneben haben die Regeln natürlich auch noch den Sinn, Kollisionen zu verhindern. Hier hakt der Vergleich dann auch etwas, da Menschen normalerweise nicht mehrfach durch die Enden verschickt werden können.