Summary

  • RFC 3153 let a PPP receiver offer to accept multiplexed frames in one direction. A successful PPPMuxCP exchange permitted the transmitter to use the format; it did not require a single multiplexed frame to be sent.
  • A negotiated default PID defined how an omitted protocol identifier would be reconstructed. It did not prove that the sender cleared PFF, omitted a field or saved a byte.
  • Actual benefit depended on emitted subframes, traffic mix, queue timing, MRU and size limits, error behavior and layer ordering. Capability, wire use, packet recovery and application outcome require separate receipts.

The bargain concerned envelopes, not payloads

Small packets can carry a disproportionate amount of framing. PPP in HDLC-like framing surrounds each packet with link material, a protocol field and a frame check sequence. Some fields can themselves be negotiated away or compressed, yet RFC 3153 observed that separately encapsulated packets still pay overhead. When PPP is carried through a tunnel such as L2TP, the repeated cost can grow again.

The proposal was straightforward: put several PPP packets into one outer PPP frame. A compact delimiter before each subframe tells the receiver whether a protocol identifier is present and how many bytes belong to that subframe. One outer frame can then carry payloads that would otherwise each have required their own full envelope.

That arithmetic sounds automatic only when time is excluded. A transmitter cannot combine packets that have not arrived. Waiting for another eligible subframe can increase delay even as the resulting frame reduces overhead per packet. RFC 3153 says so explicitly: implementers must balance multiplexing and demultiplexing delay against framing efficiency as the aggregate grows.

The standard therefore did not promise “small packets become faster.” It provided a format and enough local choice to make the trade. The number of bytes saved, time spent waiting, serialization interval, outer-frame loss and downstream effect remained observations.

The receiver offered a language; the sender chose whether to speak it

PPPMuxCP is the control protocol for the option. During the Network Control Protocol phase, a receiver can advertise that it will accept PPP multiplexed frames. The peer may not transmit such frames without that offer. Reception support is negotiated independently in each direction, so one side's successful negotiation says nothing about the reverse path.

Most importantly, success does not compel transmission. The RFC states that a peer is not obliged to send multiplexed frames after PPPMuxCP has been negotiated. It may choose which PPP frames to aggregate, and it may send eligible packets separately.

This makes an “enabled” flag an incomplete historical record. It can mean that a receiver offered the format, that the exchange reached an open state, that a default value was accepted, that a sender configured a policy, that multiplexed data appeared on the link—or merely that a management interface collapsed all those conditions into one word.

A defensible audit keeps direction explicit. It records who offered reception, which Configure messages were acknowledged, when the state became usable, and whether frames with the PPP Multiplexed Frame protocol value later appeared in that direction. Control-plane permission and data-plane exercise are joined evidence, not synonyms.

The default PID saved nothing until a bit was actually cleared

Every PPPMuxCP negotiation includes a default protocol identifier. The receiver offers the value it will assume if the first subframe omits its protocol field. If the first packet uses that protocol, the transmitter may clear the Protocol Field Flag, PFF, and leave out one or two bytes depending on ordinary PPP protocol-field compression.

“May” carries the mechanism. The transmitter is not required to remove the field even when the default would allow it. Agreement on the number establishes a reconstruction rule; it is not evidence that PFF was zero, that the field was absent or that the promised byte saving occurred.

Later subframes can omit a repeated protocol identifier in the same way. The transmitter tracks the latest explicit value in Last_PID; the receiver maintains Last_rcvd_PID. A subframe with PFF set carries a new protocol identifier and updates the state. A subframe with PFF clear inherits the current value. At the beginning of a multiplexed frame, both sides derive the state from the negotiated default.

This is small state, but it is still state. A capture must parse the delimiter, the PFF and the protocol field in sequence. Counting a configured default is no substitute. Nor is counting outer frames sufficient: two implementations can emit the same number of aggregates while making different field-omission choices.

The length field turned efficiency into a bounded local decision

Each delimiter also carries LXT and LEN. LXT selects a one-byte or two-byte length field; the remaining bits describe the subframe size. The example transmitter in RFC 3153 uses a configurable maximum subframe length, MAX_SF_LEN, and refuses candidates that exceed it. It also stops before the complete aggregate would exceed the MRU negotiated through LCP.

The third natural stop is the empty queue. An implementation may add a timer so that an incomplete aggregate does not wait indefinitely for another packet. The RFC further notes that an operator may keep the multiplexed packet substantially smaller than MRU for latency and packet-error reasons.

Those rules make “fill it as much as possible” a poor account of the design. A larger container can amortize more outer overhead. It can also delay the earliest subframe while the sender waits, and one damaged or lost outer frame can affect more inner packets. The right boundary changes with link rate, error rate, traffic burstiness, protocol mix, queue depth and the application's sensitivity to delay.

MRU is therefore a hard ceiling, not a performance recommendation. MAX_SF_LEN is an eligibility control, not a measured optimum. A timer is a local policy, not part of the peer's receive offer. Each belongs in a different receipt.

Demultiplexing had to restore packets without changing their order

On receipt of an outer frame marked with protocol value 0x0059, the decoder walks its subframes in order. It reads each length, obtains or reconstructs the protocol identifier, and hands the recovered packet to ordinary PPP processing. If a length claims more data than remains, the last subframe is dropped; the offending value may have appeared in that subframe or earlier in the parse.

The format cannot be nested inside itself. LCP frames must not be placed inside multiplexed frames. And mixing standalone packets with multiplexed packets does not authorize reordering: the RFC says neither transmitter nor receiver should change packet order regardless of container choice.

That requirement is easy to lose in a summary counter. “Three subframes decoded” does not establish where they sat relative to standalone frames before and after the aggregate. A useful trace preserves outer arrival order, delimiter boundaries, reconstructed protocol state and the order in which the receiver delivered each recovered packet.

Recovery is still not application delivery. The decoder can produce a syntactically valid PPP packet that a later layer drops, delays or transforms. The link receipt must be joined to downstream observation rather than promoted into an end-to-end result.

The stack order was part of the protocol, not an implementation footnote

PPPMux did not live alone. With Multilink PPP, the option is negotiated for the bundle, not independently on each member link. On transmission, multiplexing happens before Multilink encapsulation, so an MP header sits outside a PPPMux header. A Multilink frame itself must not be carried as a multiplexed subframe.

Compression and encryption control add another ordering constraint. PPP multiplexing runs after bundle-level CCP or ECP processing and before MP and any per-link CCP or ECP. An implementation that cannot place PPPMux above the per-link form must reject that per-link protocol when multiplexing has been negotiated.

These are not merely boxes in an architecture diagram. They determine which bytes each function sees and whether two peers reconstruct the same sequence. Two devices can each claim support for PPPMux, Multilink, compression and encryption while failing to compose them in a compatible order.

The evidence must therefore identify the layer at which a capture was taken. A trace before MP is not interchangeable with one on a member link. A control acknowledgment for ECP does not prove encryption was active around a particular aggregate. Feature inventories are not execution order.

“No additional security considerations” was not a security property

RFC 3153 says it adds no security considerations beyond those applying to PPP and header-compression schemes over PPP. That statement bounds what the document introduces. It does not give PPPMux authentication, integrity, confidentiality or replay protection.

Nor does the presence of an ECP ordering rule prove that ECP was negotiated or that its protection succeeded. A malformed subframe length, parser disagreement or loss of reconstruction state can matter operationally without constituting a new threat class invented by the multiplexing RFC.

Security claims require their own receipts: PPP authentication state, encryption negotiation, keys and algorithms where observable, frame integrity, rejection behavior and the effect on later layers. A parser that accepted a multiplexed frame demonstrated format handling, not trust.

Permission was the minimum common layer; benefit remained local and measurable

RFC 3153's design is revealing because it did not confuse interoperability with mandatory optimization. The receiver controlled the format it was willing to decode. The sender could use that permission according to current traffic and local policy. Deterministic flags and length rules made the wire format interoperable, while queue and timing choices remained with the participant running the link.

That is voluntary adoption at packet scale. Refusing to aggregate an eligible frame did not make the peer non-compliant. Sending an aggregate without the receiver's offer did. The common layer defined the compatibility boundary; running code decided when to cross it.

The distinction protects historical truth. A negotiation log can prove that the option was available. A packet capture can prove that an aggregate was emitted and how its fields were encoded. A receiver trace can prove reconstruction. Paired measurements can estimate bytes saved and waiting introduced. Only the downstream system can show whether the application benefited.

The lasting lesson is not that multiplexing always wins. It is that a protocol can make an optimization possible without claiming it has occurred. RFC 3153 gave the receiver a way to say “I can understand this.” It left the sender—and the evidence—to answer “Did you use it, and did it help?”

Sources