Summary

  • The 30 September revision of the MASQUE working-group CONNECT-ETHERNET Internet-Draft says an Ethernet frame that exceeds the available QUIC DATAGRAM capacity MUST be dropped and MUST NOT be repackaged as a DATAGRAM capsule. A frame exceeding the egress interface, network or receiver limit must also be dropped; implementations should count those losses.
  • The revision reverses the previous draft's treatment of the Frame Check Sequence. Context ID 0 now carries the Ethernet frame only through the byte before FCS. The original FCS is not an end-to-end receipt inside this tunnel. Revision 15 remains an Internet-Draft under IESG evaluation, not an RFC or evidence of a deployment failure.

Imagine a link monitor that reports an HTTP tunnel as established. The proxy accepted the request, the two endpoints can exchange tunnel traffic, and a dashboard displays green. None of those facts answers whether the next Ethernet frame fits the mode in use. Revision 15 turns that gap from a vague performance concern into two explicit drop decisions. It is news for operators who might otherwise treat tunnel setup as a proxy for frame delivery.

The draft describes two ways of moving frames. With HTTP/3 and the QUIC DATAGRAM extension, a frame occupies an unreliable datagram. Its ceiling is not merely a nominal link MTU: the maximum QUIC DATAGRAM payload has to pay the HTTP Datagram framing overhead too. If an arriving frame cannot fit, the endpoint must discard it. The new text specifically forbids rescuing that individual frame by moving it into a DATAGRAM capsule. Path-MTU discovery may inform the interface MTU over the connection's life, but it cannot make the over-budget frame fit retroactively.

Capsules are the other operating mode. HTTP/1.1, HTTP/2 and HTTP/3 without QUIC DATAGRAM carry them over a reliable stream. A capsule can span several TCP or QUIC packets and thus carry a frame larger than the path MTU. That is a mode choice, not an on-the-fly escape hatch from the first mode's mandatory drop. The distinction matters because a test that sends only small frames can validate the tunnel while never exercising the case that fails under load or a changed path.

There is a second size boundary after decapsulation. If the receiving interface, attached network or endpoint cannot accept the reconstructed frame, the draft says to drop it regardless of transport mode. It recommends a counter for oversized drops. That counter is a narrow but useful receipt: it can show that the frame was refused at a specific limit. It cannot by itself identify every upstream cause of a failed application exchange, and the draft offers no universal telemetry schema.

The FCS edit is more subtle. Revision 14 said the full Ethernet frame included the Frame Check Sequence and justified carrying it rather than letting proxying endpoints recompute it. Revision 15 defines the Context ID 0 payload as stopping immediately before FCS. It explains that ordinary network interfaces remove FCS on ingress and generate a new one on egress, making carriage of the old value both awkward and unnecessary for this encoding. That does not mean Ethernet traffic has no error checks. It means this proposal does not preserve the original link's FCS as an end-to-end artifact, and an operator should not claim that it does.

A later extension could define another encoding.

The document calls the emulated connection a point-to-point Ethernet link. Connecting that link to a wider broadcast domain still leaves bridging, loop prevention and related responsibilities with endpoints or other components. VLAN tags are forwarded by default; if endpoints interpret or rewrite them, they need agreement that this draft does not standardize. A proxy may map separate VLANs to distinct URIs for scheduling and policy. None of that turns a successful HTTP response into proof that every intended frame traversed both the tunnel and the attached Ethernet segment.

Procedurally, this is an active working-group Internet-Draft submitted to the IESG. The Datatracker lists AD Followup and an unresolved DISCUSS; it is intended for Proposed Standard but has not become one. No measured loss rate, vendor behavior, outage or interoperability result follows from the text. The relevant change is to the proposed contract, and the operational question is whether tunnel observability preserves the difference between session establishment and frame admission.

Sources