Zusammenfassung

  • draft-ietf-tiptop-quic-profile-00 empfiehlt für tiefe Weltraumpfade eine konfigurierbare, ratenbasierte Steuerung im offenen Regelkreis, weil Rückmeldungen spät eintreffen und planmäßige Speicherzeiten fälschlich wie Überlast aussehen können.
  • Sobald ein Missionsplan RTT, Pacing, Fenster, MTU oder ACK-Verhalten bestimmt, braucht seine Projektion in den Transport einen versionierten Beleg für Herausgeber, Genehmigung, Pfad, Zeit, Kapazitäts- und Pufferannahmen, Berechnung, Priorität, Ablösung, Rückfall und spätere Messung.

Der Kalender öffnet den Sender

Ein Marsorbiter sieht ein Fahrzeug an der Oberfläche vielleicht zehn Minuten lang und erst knapp zwei Stunden später wieder. Der Sender auf der Erde kann die freie Kapazität nicht wie gewohnt ertasten und danach hochfahren. Bis die Bestätigungen zurück sind, ist der nutzbare Abschnitt womöglich vorbei. Wartet ein Paket im Orbiter auf den nächsten Abstieg, ist diese Verzögerung außerdem nicht zwingend eine überfüllte Warteschlange.

Die Mission weiß davon vor dem Transport. Bodenstationen richten Antennen aus, Spektrum wird zugeteilt, Rechen- und Speicherressourcen werden reserviert, und mehrere Organisationen stimmen einen Kontakt ab. Ein Plan sagt, wann ein Pfad besteht und welches Teilstück ihn begrenzt. Die Managementebene übersetzt dieses Wissen in QUIC-Einstellungen.

Genau diese Verschiebung beschreibt QUIC Profile for Deep Space. Die Version 00 erschien am 10. September 2026 als TIPTOP-Arbeitsgruppendokument und löste den individuellen Entwurf draft-many-tiptop-quic-profile ab. Der Aufruf zur Übernahme endete am 2. September. Das Dokument bleibt ein veränderlicher Internet-Draft mit beabsichtigtem Informational-Charakter; es ist kein RFC und stellt keinen IANA-Antrag. Die Übernahme belegt ein Arbeitsmandat, nicht IETF-weiten Konsens, Einsatz oder eine Garantie für jede Empfehlung.

Der Ausgangspunkt ist dennoch greifbar. Übliche QUIC-Stacks beginnen mit Annahmen für Latenzen im Millisekundenbereich und weitgehend durchgehende Erreichbarkeit. Im Weltraum kommen Minuten der Ausbreitung, Stunden zwischen Kontakten und Speicherzeiten in Relais hinzu. Der Transport sieht verstrichene Zeit, aber nicht deren orbitale Ursache.

Geschlossene Rückkopplung beschreibt die Vergangenheit

Auf der Erde ist der geschlossene Regelkreis eine dezentrale Form von Ordnung. ACKs, RTT, Verlust und ECN erlauben Sendern, gemeinsam genutzte Kapazität zu respektieren, ohne dass ein zentraler Planer jeden Fluss vorher zuteilt. Das Netz meldet Folgen, der Algorithmus reagiert.

Bei planetaren RTTs ist diese Folge alt, wenn sie ankommt. Ein Relais kann Daten planmäßig speichern, weil das nächste Glied noch nicht sichtbar ist. Ein verlustbasierter Regler deutet die Wartezeit oder Kanalverluste als Überlast und verkleinert sein Fenster. Die im Entwurf genannten Simulationen liefern die Daten am Ende zuverlässig, benötigen mit konventioneller Steuerung aber mehr Zeit oder verpassen ganze Umläufe.

Darum soll ein Deep-Space-Stack ratenbasierte Steuerung im offenen Regelkreis unterstützen. Fenster, Sendetakt, erwartete RTT und weitere Größen können aus zeitplangesteuerten Hinweisen der Management- oder Kontrollebene stammen. Die ACK-Häufigkeit kann zeitabhängig werden, die bekannte Pfad-MTU von einem Routenorchestrator kommen. Liegt die Rate oberhalb des langsamsten nachgelagerten Links, steigt nicht der Durchsatz; nur der knappe Speicher des Orbiters füllt sich.

Ein offener Regelkreis ist keine herrschaftsfreie Zone. Die Entscheidung wandert aus dem Endpunktalgorithmus in die Organisation, die den Plan erstellt, genehmigt und verteilt.

Die erste RTT ist eine genehmigte Annahme

Vor dem ersten ACK gibt es keine gemessene RTT dieser Verbindung. RFC 9002 benötigt trotzdem einen Ausgangswert für frühe Verlustzeitgeber. Die häufigen 333 Millisekunden terrestrischer Implementierungen sind für Mars unbrauchbar.

Im intermittierenden Erde–Mars-Szenario addiert der Entwurf zur Laufzeit auch die maximale Wartezeit bis zum nächsten Relaiskontakt. Ein zu kleiner Wert erzeugt nutzlose Probes oder beendet die Verbindung vor der ersten Antwort. Ein viel zu großer Wert hält sie offen, kann die Wiederholung eines verlorenen Initial-Pakets aber um viele Stunden verzögern. Der Ausgangswert soll deshalb den erwarteten Höchstfall abdecken, ohne ihn willkürlich zu vervielfachen.

Dieser Höchstfall ist kein Messergebnis des Protokolls. Menschen wählen Orbitaldaten, Relais, Fehlerfälle und Sicherheitsmargen aus. Der Wert ist technisch erforderlich, trägt aber eine institutionelle Herkunft. Spätere Stichproben dürfen das nächste Modell verbessern; sie dürfen den früheren Plan nicht rückwirkend als Messwissen ausgeben.

Auch max_idle_timeout ist kein einseitiger Fakt. Wirksam wird der kleinere Wert beider Peers. Ein Ende kann eine sechsstündige Unterbrechung planen und trotzdem am kürzeren Timer der Gegenseite scheitern. Lokale Richtigkeit beweist keine gemeinsame Betriebsabsicht.

Aus einer Prognose wird vollziehbare Politik

Ein Kontaktplan kann zunächst nur beschreiben: Antenne A sieht Orbiter B von 14:06 bis 14:16, der Zubringer bietet eine Rate, der Abstieg eine andere. Sobald diese Felder Pacing und Fenster setzen, haben sie eine andere Wirkung.

Die erste Grenze ist Zuständigkeit. Raumfahrzeugbetreiber, Bodennetz, Relaisbesitzer, Kapazitätsanbieter und organisationsübergreifender Planer halten jeweils Teile der Befugnis. Eine gültige Signatur nennt den Absender, beweist aber nicht sein Recht auf ein gemeinsam genutztes Funkfenster.

Die zweite ist Reichweite. Ein Plan gilt für Mission, Peer, Richtung, Pfad und Dienstklasse. Dieselbe Maschine darf daraus keine allgemeine Einstellung für lokale oder spätere Verbindungen ableiten.

Die dritte ist Zeit. Ephemeriden, Wartung und Reservierungen ändern sich. Erstellung, Freigabe, Aktivierung, Ablauf und Ablösung sind getrennte Ereignisse. Vor einer Sonnenkonjunktion hochgeladene Regeln können wochenlang nicht korrigierbar sein.

Die vierte ist Konflikt. Zwei echte und jeweils genehmigte Pläne können dieselbe Antenne, Frequenz, nachgelagerte Strecke oder denselben Puffer beanspruchen. Ein QUIC-Stack darf institutionelle Priorität weder aus dem jüngsten Zeitstempel noch aus der höchsten Rate erfinden.

Ein Beleg für die Projektion in den Stack

Jede folgenreiche Übersetzung vom Plan in den Transport sollte einen kompakten, versionierten Beleg erzeugen. Vertrauliche Missionsdetails können geschützt bleiben; verantwortliche Betreiber müssen dennoch rekonstruieren können, weshalb die Verbindung zu einem bestimmten Zeitpunkt so sendete.

Der Beleg verbindet ausgebende Organisation und genehmigende Rolle; Mission, Endpunkte, Richtung und Pfad; Plan-ID und übergeordneten Datensatz; Beginn, Ende und Verfall; zugrunde liegende Ephemeriden, Beobachtungen oder Kapazitätszusagen; minimale und maximale RTT; Pacing, Fenster, ACK-Regel, Idle-Timeout und MTU; Formeln, Einheiten und Margen.

Hinzu kommen Engpass, Relaiskapazität, Pufferreservierung, Dienstpriorität und Konfliktregel. Auch die Version der Projektion ist nötig, die aus Planfeldern API-Aufrufe erzeugt. Derselbe Plan kann nach einer Softwareänderung andere Einstellungen ergeben.

Der Rückfall darf nicht implizit bleiben. Was geschieht bei fehlendem, abgelaufenem, unbekannt signiertem oder nicht mehr zum Pfad passendem Plan: Ablehnung, degradierter Betrieb, letzter gültiger Satz oder terrestrische Defaults? Gerade die scheinbar neutrale Rückkehr zum Default kann eine Deep-Space-Verbindung unmöglich machen.

Eine neue Version verweist auf ihren Vorgänger und erklärt, ob offene Verbindungen umgestellt werden. Beide Peers protokollieren angebotenen, akzeptierten und aktiven Wert. „Vom Kontrollzentrum gesendet“ ist kein Nachweis, dass ein entfernter Endpunkt die Anweisung erhielt.

Beobachtungen folgen getrennt: tatsächlicher Kontaktbeginn, RTT-Messungen, Bytes, Verlust, Puffermaximum und verpasste Gelegenheiten. Sie prüfen die Prognose. Sie überschreiben nicht die Annahme, auf deren Grundlage die alte Entscheidung fiel.

Koordination ist eine Betriebsschnittstelle

Die TIPTOP-Charta sieht Abstimmung mit QUIC, TLS, TVR, DNSOP, DTN, CCSDS, Raumfahrtagenturen und privaten Betreibern vor. Das Profil berührt geplante Attribute, ACK-Frequenz, Careful Resume, Schlüsselwechsel, MTU und Zwischenspeicherung. An jeder Übergabe kann der Wert weitergehen und seine Herkunft zurückbleiben.

Eine brauchbare API muss deshalb mehr als initial_rtt setzen. Sie muss Plan, Pfad, Geltungszeit und Ablöseregel an die Zahl binden. Telemetrie trennt extern angebotenen, vom Stack angenommenen und tatsächlich aktiven Wert. Bei Widerspruch gilt eine vorab legitimierte Konfliktregel, nicht stillschweigend „last writer wins“.

Das verlangt keine planetare Zentralbehörde. Verschiedene Institutionen können selbstständig entscheiden. Interoperabilität entsteht, wenn der Übergang zwischen ihren Zuständigkeiten lesbar bleibt: Wer beschrieb den Pfad, wer gab Kapazität frei, wer erzeugte Einstellungen und welcher Peer bestätigte sie? Ein IETF-Profil vergibt selbst keine Missionsressource.

Grenzen der Belege

Die Quellen dokumentieren keinen Flugbetriebsschaden durch einen gefälschten oder veralteten QUIC-Plan. Simulationen sind kontrollierte Versuche, keine Bestandsaufnahme eingesetzter Systeme. Version 00 kann sich ändern. Was für einen intermittierenden Mars-Relaispfad sinnvoll ist, muss auf einer kontinuierlichen Mondstrecke nicht optimal sein.

Ebenso wenig folgt daraus die Abschaffung geschlossener Rückkopplung. Messungen bleiben nützlich, sobald sie eintreffen, und der Entwurf unterscheidet Szenarien. Die Aussage ist enger: Wird eine externe Prognose zur aktiven Transporteingabe, gehören ihre Autorität, Ableitung, Geltung und Rückmeldung zur Netzkorrektheit.

Die extreme Entfernung macht nur sichtbar, was Automatisierung auch anderswo tut. Sie entfernt Entscheidungen nicht, sondern verlegt sie in vertrauenswürdige Daten. Bei Deep-Space-QUIC beginnt die erste Überlastentscheidung bereits im genehmigten Missionsplan.

Quellen

  1. IETF Datatracker — QUIC-Profil für den Weltraum
  2. Versionshistorie
  3. Archivierte Version 00
  4. Quellrepository des Entwurfs
  5. TIPTOP-Charta
  6. Ankündigung des Arbeitsgruppendokuments
  7. Aufruf zur Übernahme
  8. Ergebnis des Aufrufs
  9. TIPTOP-Protokoll von IETF 126
  10. Deep-Space-Eigenschaften und Anwendungsfälle
  11. IP-Architektur für den Weltraum
  12. RFC 9000 — QUIC
  13. RFC 9002 — QUIC-Verlusterkennung und Überlaststeuerung
  14. RFC 9308 — Anwendbarkeit von QUIC
  15. RFC 9959 — Careful Resume
  16. Entwurf zur QUIC-ACK-Häufigkeit
  17. YANG-Modell für geplante Attribute
  18. BBR-Entwurf
  19. IANA-QUIC-Register
  20. Deep-Space-QUIC-Simulationsumgebung