= Solution
Reserve a <frame delimiter> that cannot occur inside encoded <data-link frame> contents. For a concrete <bit stuffing> rule, take the flag `01111110`. Between flags the sender inserts a zero after every run of five consecutive one <bits>, including runs in the checking information. The receiver removes that zero when decoding. The flags themselves are transmitted without <bit stuffing>. For example, the six payload one <bits> `111111` are sent as `1111101`, so they cannot imitate the flag's run of six ones.<PPP in HDLC-like Framing (RFC 1662)>[§§5.1–5.2: flag sequence and bit-stuffed transparency]{ref}
The receiver recognizes the flag before treating input as payload. After five ones, a following zero is a stuffed <bit>; a following one cannot be ordinary stuffed payload and requires the delimiter/error handling rules. Consequently a delimiter remains recognizable even if the unencoded data contained its exact pattern. <Bit stuffing> also applies at the end of the payload, so a run cannot spill into a boundary ambiguously.
The <frame delimiter> should be long and distinctive enough to support reliable synchronization in the presence of errors, but frequent flags and the run constraint cost capacity. For the usual family of flags with a longer run of ones, a longer forbidden run makes stuffing less frequent while making the delimiter itself longer. Valid stuffed data never contains an intact flag; false flags can arise when transmission errors damage that guarantee. Their likelihood depends on the error model, rather than merely on the raw frequency of the unencoded pattern.
The <data-link frame> length balances fixed header/flag/check overhead against <network latency>, receiver storage and the cost of a damaged <data-link frame>. If independent <bit> errors have <probability> $p$, an $N$-<bit> transmission has no such error with <probability> $(1-p)^N$. Longer <data-link frames> amortize fixed overhead, but have more opportunities for corruption and, when <data retransmission> is used, waste more work per failed attempt. They also delay delivery until the whole <data-link frame> is available. A maximum length limits storage requirements and the damage from a lost boundary. The design balance is
$$
\boxed{\text{unambiguous flags; low stuffing overhead; bounded delay and error-recovery cost}.}
$$
Back to article page
