Summary

  • RFC 1692 führte TMux als Bündelung kurzer Telnet- und Rlogin-Segmente für dasselbe Ziel ein, um weniger IP-Pakete und Host-Interrupts zu erzeugen.
  • Ein Router, der TCP-Ports filterte, sah im äußeren Paket nur IP-Protokoll 18. Der RFC verlangte Prüfung der inneren Segmente oder Blockierung von TMux. RFC 4450 stufte die Spezifikation später als Historic ein.

Ein einziger Tastendruck erzeugt ein kleines Paket. Viele gleichzeitig geöffnete Terminals schicken solche Pakete an wenige Hosts. Der Link kann noch reichlich Bandbreite haben, während ein Host jedes einzelne Paket annehmen und verarbeiten muss. Der RFC 1692 vom August 1994 stellte die Gegenüberstellung auf: Ein Paket mit einem Oktett Nutzlast kann nahezu so viel Hostarbeit kosten wie eines mit 1500 Oktetten. Die knappe Ressource war in diesem Bild die Zahl der Pakete pro Sekunde.

Peter Cameron, David Crocker, Danny Cohen und Jon Postel bauten TMux als Verpackung zwischen IP und Transport. Mehrere kurze Segmente für dasselbe Hostpaar teilten sich einen IP-Datagrammkopf. Jedes erhielt einen vier Oktette langen Minikopf mit Länge, ursprünglichem Transportprotokoll und eigener Prüfgröße. Außen stand Protokollnummer 18. Der Empfänger zerlegte das Datagramm wieder und gab die Segmente wie gewöhnlich an TCP oder UDP ab. Für die Anwendung änderte sich an ihrer Sitzung nichts.

Die Ersparnis entstand erst, wenn vor dem Versand genug Material zusammenkam. Beim ersten Segment startete ein Timer; weitere Segmente konnten bis zu dessen Ablauf mitfahren. Der RFC nannte 20 bis 30 Millisekunden als konfigurierbaren Richtwert und etwa ein Zehntel einer Sekunde als wahrscheinliche Obergrenze wegen der Antwortzeit interaktiver Terminals. Ein voller Puffer wurde sofort verschickt. Größere Segmente, beispielsweise oberhalb von 700 Oktetten, sollten einzeln reisen. Ein Umschlag mit nur einem Segment erhöhte vor allem die Wartezeit.

Vor dem ersten Bündel musste der Sender die Fähigkeit des Empfängers kennen. Ein gültiges eingehendes TMux-Paket lieferte einen Hinweis; ein leeres Protokoll-18-Datagramm als ENQ konnte den Austausch eröffnen. Unbeantwortete Anfragen wurden in wachsenden Abständen wiederholt, während normale Pakete weiterliefen. Gespeicherte Fähigkeiten hatten eine zeitliche Grenze: Ein Neustart des Zielhosts konnte den Zustand ändern. TMux war damit keine unwiderrufliche Umstellung einer Verbindung.

Die schärfste Rechnung stand im Abschnitt zur Sicherheit. Ein Router mit Regeln nach TCP-Port erkannte bei TMux nur die äußere Protokollnummer. Die Ports lagen im Inneren. Große Segmente derselben TCP-Verbindung konnten separat als normale IP/TCP-Pakete erscheinen und anders beurteilt werden. RFC 1692 verlangte deshalb von einem portfilternden Router ohne TMux-Kenntnis, TMux in beiden Richtungen zu sperren. Ein TMux-fähiger Router durfte die einzelnen Segmente prüfen und unzulässige entfernen.

TMux war zunächst ein Proposed Standard. In einer Überprüfung alter Vorschläge von 2004 bis 2005 ging es darum, ob Implementierungen neu geschrieben oder weiter gepflegt würden. RFC 4450 führte TMux unter den nach Historic verschobenen Dokumenten auf; der RFC Editor zeigt diesen Status heute. Der Host bekam weniger Pakete. Der Router bekam weniger sichtbare Merkmale. Beides war eine Folge derselben Verpackung.

Quellen