Zusammenfassung

  • Die am 30. September aktualisierte Arbeitsgruppenfassung verlangt, einen Ethernet-Frame zu verwerfen, der die tatsächlich verfügbare QUIC-DATAGRAM-Kapazität überschreitet. Für genau diesen Frame ist ein Wechsel zur DATAGRAM-Kapsel ausdrücklich untersagt. Auch ein nach der Entkapselung zu großer Frame muss verworfen werden, wenn Ausgangsschnittstelle, Zielnetz oder Empfänger ihn nicht aufnehmen können; ein Zähler solcher Verluste wird empfohlen.
  • Revision 14 sah die Frame Check Sequence, kurz FCS, noch als Teil des transportierten Frames vor. Revision 15 endet unmittelbar vor diesem Feld, weil übliche Netzwerkschnittstellen die alte FCS beim Empfang entfernen und beim Senden eine neue erzeugen. Der Text ist weiterhin ein Internet-Draft in der IESG-Prüfung, kein veröffentlichter RFC und kein Befund über einen bestimmten Netzausfall.

Ein Tunneltest kann zugleich bestanden und unvollständig sein. Das HTTP-Verfahren liefert eine erfolgreiche Antwort, der virtuelle Port erscheint aktiv, ein kurzer Frame kommt an. Erst ein längerer Frame zeigt, ob die konkrete Transportart genug Nutzlast übrig lässt. Genau diese Lücke zwischen Sitzungsstatus und Frame-Zulassung schärft die neue Fassung. Sie macht es schwieriger, „Tunnel steht“ als Ersatz für „Verkehr kommt an“ zu verkaufen.

Der Entwurf beschreibt, wie ein HTTP-Client Layer-2-Frames über einen Server mit einem physischen oder virtuellen Ethernet-Segment austauscht. Nutzt er HTTP/3 mit QUIC DATAGRAM, kann der DATAGRAM-Frame nicht fragmentiert werden. Vom maximalen QUIC-DATAGRAM-Payload gehen außerdem die Bytes für das HTTP-Datagram-Framing ab. Die nominelle MTU einer Netzkarte reicht deshalb nicht als Kapazitätsnachweis. Passt ein ankommender Ethernet-Frame nicht in den verbleibenden Raum, muss der Endpunkt ihn verwerfen. Die neue Fassung verbietet ausdrücklich, diesen einen Frame ersatzweise als DATAGRAM-Kapsel zu schicken.

Eine während der Verbindung erkannte Pfad-MTU kann künftige Interface-Einstellungen beeinflussen, nicht jedoch einen bereits abgewiesenen Frame nachträglich retten.

Kapseln haben ihren eigenen Betriebsmodus. Über HTTP/1.1 oder HTTP/2 sowie über HTTP/3 ohne QUIC-DATAGRAM-Erweiterung laufen sie in einem zuverlässigen Stream. Ein Ethernet-Frame kann sich dabei über mehrere TCP- oder QUIC-Pakete erstrecken und größer als die MTU eines einzelnen Pfadpakets sein. Das ist eine wichtige Alternative bei der Planung, aber kein stillschweigender Fallback pro übergroßem Frame im DATAGRAM-Modus. Wer beides in einer einzigen Produktzusage zusammenzieht, verspricht unter Umständen eine Eigenschaft, die in der gewählten Betriebsart gerade nicht gilt.

Nach dem Tunnel folgt eine weitere Größenprüfung. Der rekonstruierte Frame kann zwar angekommen sein, aber das ausgehende Interface, das angeschlossene Netz oder der empfangende Endpunkt können ihn trotzdem nicht aufnehmen. Revision 15 ordnet dann ebenfalls das Verwerfen an und empfiehlt einen Zähler für übergroße Frames. Ein Eingangsverlust wegen QUIC-DATAGRAM-Kapazität ist etwas anderes als ein Ausgangsverlust am nächsten Segment. Die getrennte Messung kann die Fehlersuche eingrenzen, beweist jedoch noch nicht, warum eine Anwendung keine Antwort erhalten hat.

Auch beim FCS sollte man die Formulierungen der beiden Fassungen nicht verwischen. Die alte Version schloss die ursprüngliche Frame Check Sequence ein, um Neuberechnung an den Proxy-Endpunkten zu vermeiden. In der neuen Fassung reicht das Context-ID-0-Payload vom Zieladressfeld bis zum Byte vor der FCS. Gewöhnliche Netzwerkschnittstellen streifen diese beim Empfang ab und berechnen beim Aussenden eine neue. Das ist keine Behauptung, Ethernet hätte plötzlich keine Fehlererkennung mehr. Der Entwurf übernimmt nur nicht die alte FCS als unveränderlichen Ende-zu-Ende-Beleg durch den Proxy.

Eine künftige Erweiterung könnte eine andere Kodierung definieren.

Der so emulierte Link ist im Entwurf Punkt zu Punkt. Soll er zwei größere Ethernet-Bereiche verbinden, bleiben Bridging, Schleifenvermeidung und die Behandlung von Broadcast- oder Multicast-Frames Aufgaben der Endpunkte beziehungsweise ihrer delegierten Komponenten. VLAN-Tags werden grundsätzlich transparent weitergeleitet; eine Auswertung an beiden Enden setzt eine abgestimmte Behandlung voraus, deren Verfahren der Entwurf nicht festlegt. Für verschiedene VLANs können verschiedene URIs verwendet werden, um Richtlinien und Scheduling zu trennen. Diese Möglichkeit ist keine Garantie für Isolation oder Zustellung.

Im Datatracker steht Revision 15 als aktiver MASQUE-Arbeitsgruppenentwurf, dem IESG vorgelegt und im Zustand AD Followup mit offenem DISCUSS. Vorgesehen ist Proposed Standard, erreicht ist dieser Status noch nicht. Die Quellen enthalten weder eine gemessene Fehlerquote noch den Nachweis einer bestimmten Herstellerimplementierung oder eines Vorfalls. Der belastbare Befund ist die Änderung der vorgeschlagenen Regeln; ob ein Betreiber sie sichtbar macht, lässt sich erst an seiner Konfiguration und seinen Messungen beurteilen.

Quellen