Zusammenfassung

  • RFC 3135 untersuchte Performance Enhancing Proxies für Satelliten- und Funkstrecken: ACK-Taktung und -Filterung, lokale Bestätigung und Wiederholung, geteilte Verbindungen, Kompression, Tunnel und das Verbergen von Unterbrechungen.
  • Ein vom Proxy erzeugtes ACK belegte die Übernahme an einem Zwischenpunkt. Es bewies weder den Empfang durch den entfernten TCP-Stack noch den Abschluss in der Anwendung. Mit der kürzeren Regelschleife wanderte auch die Wiederherstellungsverantwortung in das Netz.

Die Rückmeldung überholte die Daten

Bei einem geostationären Satelliten lässt sich die Laufzeit nicht wegkonfigurieren. Muss TCP für jeden Fortschritt auf eine vollständige Hin- und Rückreise der Bestätigung warten, bleibt selbst auf einer leistungsfähigen Strecke Kapazität ungenutzt.

Ein Proxy kann Segmente vor dem langen Sprung annehmen und sofort antworten. Der Sender sieht eine kleinere RTT und hält mehr Daten in Bewegung. Ein Funkverlust kann nahe seiner Ursache repariert werden, statt den entfernten Sender eine lokale Störung als Problem des gesamten Pfads behandeln zu lassen.

Die Bytes sind damit aber nicht am Ziel. Sie können noch im Puffer des Proxys liegen, vor Satellit oder Funk, zweitem Proxy, entferntem TCP und Anwendung. Gehen sie nach dem lokalen ACK verloren, hat der Ursprung bereits Fortschritt signalisiert bekommen. Der Zwischenknoten muss die Wiederherstellung übernehmen.

RFC 3135 bezeichnete diese Funktionsfamilie als Performance Enhancing Proxies, PEPs. Das Informational RFC vom Juni 2001 war weder Internet Standard noch allgemeine Einsatzempfehlung. Es ordnete Verfahren für hohe Latenz, asymmetrische Bandbreite, Fehler, knappe Kapazität und Verbindungsabbrüche und prüfte ihre Nebenwirkungen.

Seine bleibende Frage lautete nicht nur, ob der Durchsatz steigt. Entscheidend war, welcher Akteur das beruhigende Signal erzeugt hatte.

Hinter PEP standen verschiedene Eingriffe

Ein Transport-PEP konnte TCP beobachten und verändern, während das Anwendungsprotokoll zwischen den Endpunkten blieb. Ein Anwendungs-PEP verstand und bearbeitete höhere Protokolle. Ein integrierter PEP bestand aus einem Knoten; eine verteilte Ausführung platzierte Komponenten auf beiden Seiten des belasteten Links.

Auf einer asymmetrischen Strecke konnten die Seiten unterschiedliche Aufgaben übernehmen. Die Datenseite bestätigte lokal, damit der breite Kanal gefüllt blieb. Die Rückseite filterte redundante ACKs, damit der schmale Kanal nicht von Bestätigungen verstopft wurde.

Bei einer geteilten Verbindung endete das TCP des Hosts am Proxy. Von dort begann eine zweite Verbindung zum Ziel. Zwischen zwei PEPs konnte eine dritte, linkspezifische Verbindung liegen, bis hin zu einem proprietären Protokoll über UDP. Mehrere Nutzersitzungen ließen sich darin bündeln.

Andere Eingriffe waren begrenzter. ACK spacing veränderte den Zeitpunkt, nicht zwingend den Urheber der Bestätigung. ACK filtering sparte Rückkanal. Snoop-artige Funktionen speicherten Funksegmente und reparierten Verluste lokal. Kompression reduzierte Bytes. Die Abkürzung PEP allein sagte noch nichts über die erhaltene Semantik.

RFC 3135 trennte deshalb Transparenz von End-to-End-Bedeutung. Ein für Hosts unsichtbarer Proxy konnte ihre Verbindung terminieren. Ein ausdrücklich gewählter Dienst konnte einen Anwendungsbeleg bis zum echten Ziel bewahren. Transparenz beschrieb Wissen über den Zwischenknoten, nicht dessen Beweisbefugnis.

Wer früh bestätigte, übernahm die Reparatur

Schon ein gewöhnliches TCP-ACK hat eine begrenzte Aussage. Es meldet Empfang beim TCP des Gegenübers, nicht Lesen, Speichern oder Ausführen durch die Anwendung. Braucht eine Anwendung verlässlichen Abschluss, benötigt sie eine eigene End-to-End-Prüfung mit definierter Bedeutung.

Das lokale ACK fügte eine frühere Quittung ein. RFC 3135 formulierte die Konsequenz klar: Bestätigt der PEP Daten, trägt er die Last, Verluste hinter dieser Bestätigung zu beheben. Er braucht eine Kopie der Bytes, Sequenzzustand, Timer, Kenntnis der nachgelagerten ACKs und Regeln für lokale Wiederholung.

Das konnte die Nutzung erheblich verbessern. Ein Funkverlust wurde ohne vollen End-to-End-Zyklus korrigiert. Bei einer Unterbrechung konnte der Proxy die Annahme stoppen, dem Sender ein geschlossenes Fenster zeigen, Zustand und unbestätigte Segmente behalten und später fortsetzen. Priorisierung hinter einer geteilten Verbindung konnte einen Hintergrundfluss lange anhalten, ohne beim Ursprung dieselben Timeouts auszulösen.

Mit der Verantwortung entstand eine Nachweispflicht. War der Puffer flüchtig? Waren sämtliche Bytes vor dem ACK gesichert? Was geschah bei Neustart oder Speicherdruck? Welches Ereignis bewies, dass die Verpflichtung an das entfernte TCP und anschließend an die Anwendung überging?

Das Proxy-ACK konnte wahr sein: „Bei mir angekommen.“ Falsch wurde erst die betriebliche Übersetzung in „Beim Ziel angekommen“.

Ein Datenstrom brauchte fünf getrennte Quittungen

Zuerst übergibt die sendende Anwendung Bytes an ihr lokales TCP. Danach nimmt der PEP sie an, puffert und bestätigt möglicherweise. Dann überwinden sie den beeinträchtigten Teilpfad. Das entfernte TCP bestätigt den Empfang. Schließlich erzeugt die entfernte Anwendung das Ereignis, das ihr Protokoll meint: geparst, eingereiht, dauerhaft gespeichert, gebucht oder abgeschlossen.

Kein Ereignis ersetzt das nächste. Selbst ein Anwendungs-ACK muss definiert sein; „angenommen“ kann nur Warteschlange statt dauerhafte Speicherung heißen.

Das E-Mail-Beispiel in RFC 3135 zeigte eine ausdrückliche Übergabe. Ein Relay-MTA konnte eine Nachricht nichtflüchtig speichern, auf Anwendungsebene bestätigen und weitere Zustellversuche übernehmen. Das garantierte nicht hundertprozentig das endgültige Ziel, machte aber Verwahrung und Wiederholung sichtbar.

Transport-PEPs bestätigten Anwendungsdaten im Regelfall nicht vorzeitig; die Anwendung blieb End-to-End. Diese Einschränkung ist wichtig. Dennoch wurde das erste Transport-ACK dadurch nicht zur vorgezogenen Anwendungsquittung. Dazwischen lagen weiterhin Link, Empfänger und Geschäftsvorgang.

Der Optimierer teilte das Schicksal der Verbindung

Beim End-to-End-Prinzip bleibt unverzichtbarer Verbindungszustand an den Enden. Fällt ein Router aus und existiert eine andere Route, können Pakete ausweichen, während die Hosts ihre Erinnerung behalten.

Ein PEP mit bereits bestätigten Bytes und Zustand einer geteilten Verbindung ist kein beliebig umgehbarer Router. Sein Ausfall kann die Sitzung beenden, obwohl ein alternativer IP-Pfad vorhanden ist. Nicht die Erreichbarkeit, sondern die einzige Kopie des Versprechens ging verloren.

RFC 3135 erklärte diesen Tausch nicht generell für unvernünftig. PEPs standen oft am letzten Hop ohne Alternative. Ein langer Funkabriss hätte die Sitzung ohnehin gefährdet. Nutzer konnten den zusätzlichen Fehlerpunkt gegen deutlich bessere Alltagstauglichkeit eintauschen.

Die Bedingung war informierte Kontrolle: Folgen kennen, Einsatz wählen und möglichst auch gewöhnliches End-to-End-IP nutzen können. Ein transparenter Zwangs-PEP des Zugangsnetzes schwächte diese Bedingung. Der Betreiber erhielt den aggregierten Gewinn, der Hersteller kontrollierte Puffer und Recovery, die Anwendung trug den Verlust.

End-to-End-IPsec nahm dem Proxy die Sicht

ACKs, Sequenzen, Fenster und Optionen lassen sich nur mit sichtbaren TCP-Headern verarbeiten. Eine geteilte Verbindung erfordert Transportterminierung; Anwendungsbearbeitung benötigt noch mehr Inhalt.

IPsec ESP zwischen den tatsächlichen Endpunkten verbarg Header und Nutzlast. RFC 3135 stellte fest, dass viele PEPs dann nicht optimal oder überhaupt nicht arbeiteten. Selbst ACK spacing, das Semantik erhalten konnte, musste die betreffenden Bestätigungen erkennen.

Sicherheit am Proxy zu terminieren und dahinter neu aufzubauen schützte beide Leitungssegmente, aber nicht End-to-End. Die Daten lagen im PEP zur Verarbeitung offen. Die Endpunkte mussten dem Zwischenknoten vertrauen. Unterschiedliche Schutzniveaus auf beiden Seiten konnten außerdem einen falschen Eindruck über die gesamte Verbindung erzeugen.

Ein Tunnel zwischen den PEPs, selektiver Bypass oder Anwendungssicherheit konnten Teile des Problems mildern. Sie zeichneten die Vertrauensgrenze neu, beseitigten sie aber nicht.

Spätere RFCs zeigen die Dauerhaftigkeit. RFC 3449 verlangte für mehrere Asymmetrieverfahren sichtbare IP/TCP-Header und Flow-Erkennung. RFC 8404 und RFC 8517 dokumentierten den späteren Konflikt zwischen Verschlüsselung und Transportfunktionen im Netz. RFC 8684 berücksichtigte proaktiv bestätigende PEPs in den Wiederholungsregeln von Multipath TCP. Das belegt eine Designlinie, keine Verbreitung im Jahr 2001.

Das Verbergen der Störung veränderte die Diagnose

Eine kurze Funkunterbrechung zu verbergen konnte eine Sitzung retten. Der Proxy hielt Zustand, bremste den Sender und setzte nach Rückkehr fort.

Dieselbe Funktion verzögerte die Erkenntnis eines langen Ausfalls. Der Endpunkt blieb in einem plausiblen TCP-Zustand, obwohl nach dem Proxy nichts weiterging. Eine Anwendung mit Ausweichweg konnte den Wechsel zu spät einleiten.

Ping und traceroute maßen möglicherweise etwas anderes. ICMP konnte den PEP umgehen, ihn ohne TCP-Behandlung passieren oder eine Antwort vom Proxy selbst erhalten. Ein grüner Ping bewies dann nur Erreichbarkeit bis zum Zwischenknoten. Traceroute zeigte Router, aber nicht die TCP-Teilung und den Pufferzustand.

Asymmetrisches Routing konnte eine Hälfte eines verteilten PEP-Paars umgehen. Mobilität verlangte rechtzeitige Zustandsübergabe an einen neuen Knoten. Skalierung setzte weitere Grenzen: Verarbeitung oberhalb von IP und Zustand pro Verbindung kosteten mehr CPU und Speicher als Weiterleitung. Parallele PEPs benötigten zusätzliche Flow-Affinität.

Der Mechanismus, der einen schlechten Link unsichtbar machen sollte, brauchte daher einen eigenen, unabhängigen Funktionsnachweis.

Eine Bestandsaufnahme war kein allgemeines Urteil

RFC 3135 war Informational. Beispiele aus VSAT, Funk-WAN, WAP und Snoop erklärten Motive und Entwürfe. Sie waren keine Marktstatistik, kein kontrollierter Produktvergleich und kein Beleg, dass jeder PEP Sicherheit oder Zuverlässigkeit bricht.

Die Autoren hielten das End-to-End-Prinzip für den vorherrschenden Ansatz. PEPs sollten auf besondere Umgebungen begrenzt bleiben, in denen gleichwertige Endsystemverfahren fehlten; neue Linktechnik sollte sie nach Möglichkeit unnötig machen. Zugleich verschwanden physikalische Latenz und Kosten nicht durch Architekturtreue.

RFC 3234 ordnete PEPs später in eine umfassendere Middlebox-Taxonomie ein. RFC 3426 nutzte RFC 3135 als Fallstudie: Leistungsgewinn gegen Einschränkung von End-to-End-IPsec, neuen Fehlerpunkt, schwerere Diagnose, asymmetrisches Routing und Mobilität. Erst beide Seiten ergaben eine vollständige Bilanz.

Leistung messen, Verwahrung nachweisen

Eine belastbare Prüfung beginnt mit Richtung, Topologie, nativer RTT, Fehlern, Asymmetrie, Unterbrechungen, Last und Anwendungskriterium. Danach werden Eigentümer, Version, Position, Mechanismen, Transparenz, Teilung und Bypass des PEP festgehalten.

Für jeden Vorgang braucht es getrennte Zeiten für Senden, lokales ACK, Puffereingang, Persistenz, nachgelagerte Übertragung, lokale Wiederholung, entferntes TCP-ACK, Anwendungs-ACK und dauerhaften Abschluss. Wer wiederholte, welcher Timer auslöste, was ein Neustart löschte, wie beide Richtungen verliefen und ob Handover oder Failover gelang, gehört dazu.

Auch Sicherheitsendpunkte, sichtbare Header, Klartext im Proxy, Bypass-Regeln und Schutzunterschiede müssen erhalten bleiben. Throughput und scheinbare RTT werden mit Anwendungszeit und Korrektheit verglichen.

Warnzeichen sind Widersprüche: ACK vor belastbarer Verwahrung; Verlust bestätigter Daten beim Neustart; erfolgreicher Ping bei blockiertem TCP; stumm deaktivierte Optimierung durch Verschlüsselung; Umgehung des Zustands durch Rückroute; Zustandsverlust bei Bewegung; bessere Transportwerte bei schlechterem Anwendungsergebnis.

RFC 3135 verkürzte eine Regelschleife, nicht die Wahrheit. Der Proxy durfte zuverlässig sagen: „Die Bytes sind bei mir.“ Ohne den Beleg der entfernten Anwendung durfte er nicht in deren Namen sagen: „Sie sind angekommen.“

Sources

  1. https://www.rfc-editor.org/rfc/rfc3135.txt
  2. https://www.rfc-editor.org/info/rfc3135
  3. https://www.rfc-editor.org/rfc/rfc3135.html
  4. https://www.rfc-editor.org/rfc/rfc793.html
  5. https://www.rfc-editor.org/rfc/rfc1122.html
  6. https://www.rfc-editor.org/rfc/rfc2401.html
  7. https://www.rfc-editor.org/rfc/rfc2488.html
  8. https://www.rfc-editor.org/rfc/rfc2760.html
  9. https://www.rfc-editor.org/rfc/rfc2775.html
  10. https://www.rfc-editor.org/rfc/rfc3234.html
  11. https://www.rfc-editor.org/rfc/rfc3426.html
  12. https://www.rfc-editor.org/rfc/rfc3449.html
  13. https://www.rfc-editor.org/rfc/rfc8404.html
  14. https://www.rfc-editor.org/rfc/rfc8517.html
  15. https://www.rfc-editor.org/rfc/rfc8684.html