Zusammenfassung

  • RFC 10055 dokumentiert die von Chromium verwendeten Socket-Aufrufe für UDP-ECN auf Apple, Linux und Windows; als Informational RFC schreibt er den Plattformen keine gemeinsame API vor.
  • Ein ECN-Signal ist für die Anwendung erst nutzbar, wenn der Socket den Empfang aktiviert, Zusatzdaten je Datagramm liefert und der Code deren jeweilige Plattformform korrekt auswertet.

Der Router kann Congestion Experienced markieren, und der IP-Stack kann die Bits unverändert transportieren. Trotzdem kann der UDP-Transport ohne verwertbares Feedback bleiben. Die Lücke liegt zwischen IP-Header und Prozess: bei der Socket-Schnittstelle, die entscheidet, ob eine Markierung als Anwendungsdaten sichtbar wird.

RFC 10055 hält die Experimente fest, mit denen Chromium ECN über UDP unter Apple, Linux und Windows nutzte. Das Dokument ist Informational, keine Internet-Standards-Track-Spezifikation. Es bindet kein Betriebssystem an einen bestimmten API-Aufruf und bezeichnet seine Plattformhinweise als zeitgebundene Momentaufnahme. Für neuere Versionen verweist es auf die jeweilige Plattformdokumentation.

ECN belegt zwei Bits im IP-Header. RFC 3168 definiert die explizite Congestion Notification; RFC 9330 beschreibt die L4S-Architektur mit häufigeren expliziten Signalen. QUIC läuft über UDP. RFC 9000 sieht vor, ECN-Zähler je Pfad zu validieren und ECN bei fehlgeschlagener Validierung auf diesem Pfad abzuschalten. Das funktioniert nur, wenn der Transport die tatsächlich empfangenen Markierungen beobachten kann.

Beim Empfang unterscheidet RFC 10055 zwischen Aktivierung und Auslesen. Linux, Apple und FreeBSD verwenden IP_RECVTOS für IPv4 und IPV6_RECVTCLASS für IPv6. Die Anwendung liest die zum Datagramm gehörenden Zusatzdaten üblicherweise mit recvmsg(). Unter Linux benötigt ein dual-stack-fähiger IPv6-Socket außerdem IP_RECVTOS, wenn er ECN-Marken in IPv4-Datagrammen melden soll. Der dokumentierte Ablauf unter Apple und FreeBSD verlangt diesen zusätzlichen Schalter nicht.

Windows bietet eine andere Oberfläche. Die Microsoft-Dokumentation empfiehlt WSASetRecvIPEcn(); WSARecvMsg liefert anschließend Steuerdaten mit dem Codepoint. RFC 10055 weist jedoch auf Sonderfälle für Dual-Stack-Sockets und IPv4-abgebildete IPv6-Adressen hin. Ein allgemeines Flag „IPv6“ beweist daher nicht, dass alle eingehenden Datagramme gleich behandelt werden.

Auch das zurückgegebene Datenformat unterscheidet sich. Linux sowie Apple und FreeBSD können das vollständige DS-Feldbyte mit DSCP und ECN liefern. Windows meldet über IP_ECN beziehungsweise IPV6_ECN nur den ECN-Codepoint. Gemeinsamer Parsercode braucht diese Unterscheidung, sonst können identische Bitoperationen auf verschiedenen Systemen unterschiedliche Bedeutungen erzeugen.

Beim Senden steht eine konstante Socket-Markierung einer Kennzeichnung je Paket gegenüber. Apple, FreeBSD und Linux erlauben die Einstellung am Socket; ein Server, der sehr unterschiedliche Verbindungen über einen Socket verarbeitet, kann dagegen einzelne Datagramme markieren müssen. Im Snapshot von RFC 10055 bot Windows keine Markierung je Socket. Zusätzlich können Schreibvorgänge auf IP_TOS oder IPV6_TCLASS auf manchen Plattformen auch DSCP verändern. ECN-Code muss den vorhandenen DSCP-Wert erhalten und konkurrierende Änderungen koordinieren, statt die Dienstklasse eines anderen Stack-Bausteins zu überschreiben.

Das ist eine Frage der Beweiskette. Ein fehlender CE-Wert kann einen unmarkierten Pfad bedeuten, aber ebenso eine nicht aktivierte Socket-Option, fehlende Zusatzdaten oder einen fehlerhaften Parser. RFC 10055 nennt außerdem eine mögliche Datenschutzfolge: Ungleich verteilte ECN-Fähigkeiten können einem Gegenüber Hinweise auf das Betriebssystem geben. Der RFC quantifiziert weder Häufigkeit noch Aussagekraft dieses Fingerprints.

Eine belastbare Fähigkeitstabelle hält deshalb je Betriebssystemversion, IP-Familie und Dual-Stack-Modus fest, ob die Option angenommen wurde, welcher cmsg ankam, wie der Codepoint dekodiert wurde, ob DSCP unverändert blieb und ob der Transport seine Zähler validierte. Das empfangene CE ist nur ein Schnittstellenbeleg; es beweist weder eine Reaktion des Senders noch eine bessere Nutzerleistung.

Der kleinste gemeinsame Vertrag lautet: den ECN-Codepoint für jedes Datagramm richtig verfügbar machen und den angrenzenden DSCP-Zustand bewahren. Die Betriebssysteme können dafür ihre lokalen APIs behalten. Einheitlich und prüfbar muss das Ergebnis sein.

Quellen