Faktor 10

Latenzzeiten drastisch senken

Dieses einfache und dennoch sichere Verfahren konnte sich in der Vergangenheit bewähren, hat aber den Nachteil, daß bei steigendem Netzwerkverkehr die Anzahl der Kollisionen automatisch zunimmt. Damit sind jedoch auch immer mehr Retransmit-Aktivitäten notwendig. Diese führen wiederum zur Belastung der Infrastruktur und lassen damit den Nettodurchsatz in die Knie gehen.

Für den Anwender, der sich gerade Daten vom Internet lädt, macht sich dieser Effekt so bemerkbar, daß plötzlich die Übertragung für Sekunden stockt. Dies hängt damit zusammen, daß die Kommunikationsendpunkte den Transfer, der bei der Kollision beteiligt ist, von neuem beginnen müssen. Auf diese Weise geht wertvolle Zeit verloren, da die zwischengeschalteten Stationen - bis auf die, an der die Kollision stattfand - ihre Arbeit ja richtig machten.

Die Transferpattern im Internet sind überhaupt nicht vorhersagbar und alles andere als kontinuierlich. So kann die angeschlossene Hardware, so leistungsfähig diese auch sein mag, nicht vorausschauend agieren und ist zum Reagieren verdammt. "Das Fatale ist, daß man die Situation einer Congestion erst dann bemerkt, wenn ein Datenpaket nicht ankommt und das kann schon einmal sechs Sekunden dauern. Das ganze System kann erst dann reagieren, auch wenn der High-Speed-Switch, der das Problem längst hätte lösen können, nur 100 ms entfernt um die Ecke gelangweilt auf Arbeit wartet," bringt es Bill Jolitz auf den Punkt. Für den Endanwender stellt sich damit das Internet als unzuverlässig dar. Für Jolitz steht außer Frage, daß die Latenzzeit im Internet deutlich sinken und zugleich die Bandbreite spürbar erhöht werden muß: "Natürlich geht alles ganz schnell, wenn ich mal Zeit habe, aber wehe ich muß noch schnell wichtige Daten für eine Präsentation laden, dann geht gar nichts mehr. Oft ist das Internet so langsam, daß die Anwender mitten im Transfer abbrechen." Damit kommt der Entwickler zum Kern seiner Technik. Bisher wurde die Kontrolle im Fehlerfalle oft genug auf den Anwender abgewälzt, der einen Transfer einfach abbricht, sobald dieser zu lange dauert oder "hängt". Jolitz will die Kontrolle direkt in die Infrastruktur verlegen, um damit wertvolle Zeit zu sparen und die Bandbreite für alle zu erhöhen.

Seit den Arbeiten am BSD-Unix im Herzen der Computer Systems Research Group der University of Berkeley, kennt Jolitz das TCP/IP-Protokoll bis ins kleinste Detail und hat dieses seither als Consultant für große Firmen oft genug analysiert und Lösungen entwickelt -- vom Treiber für das von ihm entwickelte 386BSD-Unix bis hin zu Clusterlösungen für einen Workstation-Hersteller.