Seite 2: Lange Vorgeschichte

Inhaltsverzeichnis

heisenetze: Historisch scheint so etwas wie Multipath-TCP erstmals 1999 in einer US-amerikanischen Dissertation zum Multipath-Routing erwähnt worden zu sein. Den Auftakt in der IETF bildete eine Birth-of-Feather-Sitzung 2009, zehn Jahre später. Warum dauerte es so lange, bis der Gedanke Gestalt annahm?

Bonaventure: Sogar schon früher, 1995, hatte Christian Huitema in der IETF vorgeschlagen, TCP so zu erweitern, dass mehrere Adressen parallel für dieselbe Verbindung verwendet werden können; er nannte das multi-homed TCP. Aber die IETF ist ziemlich langsam und Anfang 2000 wurden neue Eigenschaften der Transportschicht hauptsächlich im Zusammenhang mit dem Stream Control Transmission Protocol (SCTP) statt für TCP diskutiert.

heisenetze: SCTP sollte ähnliche Funktionen ermöglichen, wie sie Multipath-TCP nun bereitstellt. Warum war SCTP nicht erfolgreich?

Bonaventure: Ich glaube, das hat zwei Ursachen. Erstens entschied man sich bei SCTP aus vielen guten Gründen, Anwendungen eine Alternative zu TCP anzubieten - es gibt die Möglichkeit zum Streaming, zur verbindungslosen, nichtzuverlässigen Übertragung, und so weiter. Deshalb musste SCTP eine andere API bereitstellen, was zur Folge hat, dass Anwendungen, die SCTP nutzen sollen, eigens angepasst werden müssen. Das ist bei Multipath-TCP heute nicht der Fall.

Der zweite Grund ist, dass SCTP - das die Neuentwicklung eines Transportprotokolls auf saubere Art angeht - eine andere Protokollnummer auf dem IP-Layer verwendet, damit ein Empfänger feststellen kann, dass ein IP-Paket ein SCTP-Segment enthält.

Dummerweise gibt es im Internet verschiedene Arten von Middleboxen - Firewalls, NATs und solche Dinge. Und sehr oft, wenn eine Middlebox ein Paket sieht, das sie nicht versteht, wird sie das Paket verwerfen. Viele Middleboxen verstehen nur TCP und UDP. Wenn man deshalb bei den meisten NATs, die die Leute zu Hause haben, nicht mit TCP oder UDP über IP kommt, wird man vom NAT blockiert, weil der kein SCTP versteht und keine Portumsetzung für SCTP macht. Erst seit kurzem gibt es einen Draft, der erklärt, wie man die Portumsetzung bei SCTP hinbekommt.

Das Ergebnis war so etwas wie ein Teufelskreis: Das Protokoll ist sauber und ordentlich, aber man braucht eine andere API, wenn man es verwenden will. Und Entwickler wissen, dass viele Middleboxen es dummerweise nicht unterstützen. Sie wagen nicht, es einzusetzen, weil ihre Anwendung eventuell nicht in der Lage ist, sich durch das Netz zu verbinden. Wenn umgekehrt nur wenige Anwendungen das Protokoll nutzen, dann gibt es keinen Anreiz für die Entwickler von Middleboxen, ihre Geräte so zu überarbeiten, dass sie SCTP unterstützen. Und ohne Unterstützung in den Middleboxen wird niemand die Anwendungen entwickeln oder migrieren.