#33 retain the 155.52-Mbit/s STM-1 line rate and 9×260-byte C-4 container; distinguish RFC 791's 576-octet host acceptance rule from an MTU claim; treat 24+552 bytes as a conditional model; show under RFC 2615/RFC 1662 that the POS/PPP stream may cross VC boundaries; derive 143.52 Mbit/s and 92.284% only as zero-extra-overhead upper bounds; gate actual goodput on PPP, stuffing, MTU, loss, QoS, and protection

Below are all the lines written in the notebook together with the full narration transcript.

1. 1. Fix the problem model and IP user-data service boundary

   

   Welcome back.

   The previous source's 83.17% is not standard continuous ATM mapping; D32 corrected the explicit AAL1 non-P upper bound to 85.395%.

   Today, same frame — different filling.

   This class model replaces a 53-byte ATM unit with a conditional 576-byte IP PDU; real IP-over-SDH mapping uses PPP encapsulation.

   The 24-byte non-user +552-byte user split is only the problem assumption; count IP, transport, tunnel, and link overhead at a stated service boundary.

   Four questions, same shape as last time.

   Part a: build a continuous PDU/PPP byte stream in the correct C-4 capacity; a PDU may cross its frame boundary.

   Part b: calculate long-run average user bits per STM frame under the conditional 24+552 model.

   Part c: calculate the line-efficiency upper bound in the same conditional zero-extra-overhead model.

   Part d: find the conditional upper-bound user rate; measure PPP/IP/application overhead for actual POS goodput.

   Compare ATM only under explicit, like-for-like service-boundary assumptions.

   Will big packets do better?

   Standard continuous mapping has no recurring frame-tail waste; boundary phase continues into the next frame.

   Let us walk it.

   Narration transcript

   Welcome back. In the previous video we filled an S T M one frame with A T M cells and got eighty three point one seven percent user data efficiency. Today, same frame — different filling. We replace the fifty three byte A T M cells with five hundred seventy six byte I P packets. Each I P packet has twenty four bytes of header — the I P header plus protocol stack overhead — and five hundred fifty two bytes of actual user data inside. Four questions, same shape as last time. Part a: how many complete I P packets fit inside the payload area of one S T M one frame? Part b: how many bits of actual user data does that give us per frame? Part c: what percentage of the total S T M one capacity is genuine user data? Part d: at what rate is the user information being delivered, in megabits per second? And of course, we will compare against the A T M result. Will big packets do better? Will the unused tail bite us? Let us walk it.

2. 2. Verify STM-1, AU-4, VC-4, and C-4 capacity

   

   First, a quick recap of the STM one frame.

   Nine rows by two hundred seventy columns of bytes.

   That is two thousand four hundred thirty bytes per frame, and at eight bits per byte, exactly nineteen thousand four hundred forty bits per frame.

   The first 9 columns×9 rows form a transport-overhead/pointer area carrying RSOH, the AU-4 pointer, and MSOH; it is not all section overhead.

   VC-4 POH is one column×9 rows, or 9 bytes, not three columns.

   The C-4 client container is 260 columns×9 rows=2,340 bytes/frame, with 149.76 Mbit/s client byte-stream capacity.

   And the frame still runs at eight thousand frames per second — one hundred twenty five microseconds each.

   The STM-1 line frame is fixed; client container and usable goodput must still follow the selected mapping standard.

   Client mapping, framing, fragmentation/padding, and higher-layer overhead may all change.

   Narration transcript

   First, a quick recap of the S T M one frame. Nine rows by two hundred seventy columns of bytes. That is two thousand four hundred thirty bytes per frame, and at eight bits per byte, exactly nineteen thousand four hundred forty bits per frame. The first nine columns are section overhead — eighty one bytes per frame total. Three more columns are path overhead — twenty seven bytes per frame. What remains, two hundred fifty eight columns by nine rows, is two thousand three hundred twenty two bytes — this is the payload area we get to fill. And the frame still runs at eight thousand frames per second — one hundred twenty five microseconds each. These numbers do not change between videos. Only the way we slice up the payload changes.

3. 3. Separate RFC 791's 576-byte rule from the 24+552 assumption

   

   Now the IP packet.

   RFC 791 requires hosts to accept datagrams up to 576 octets, whole or in fragments; this is not a universal safe-WAN-packet or link-MTU rule.

   The 576=24 stated non-user+552 stated-user split is a problem condition; an option-free IPv4 header is 20 bytes, a 24-byte IP header can mean IHL=6, and upper-layer encapsulation is not IP header.

   Only at this stated service boundary do we assume 552 user bytes per 576-byte class unit; PPP and application overhead are excluded.

   The conditional zero-extra-overhead PDU fraction is 552/576=23/24≈95.833%.

   For ATM, 47/53≈88.68% applies only to explicit AAL1 non-P/all-user-cell conditions, not a universal IP-versus-ATM result.

   The 24-byte overhead is fixed only in this classroom model; real header, encapsulation, and stuffing overhead can vary by format and content.

   A larger PDU amortizes fixed per-PDU overhead, while fragmentation, stuffing, loss/retransmission, latency, and MTU gates may change the result.

   Only the conditional client fractions differ by about 7.15 points; standard mapping has no recurring tail waste.

   Narration transcript

   Now the I P packet. Five hundred seventy six bytes total — historically the minimum reassembly size from R F C seven ninety one, the default safe packet size for I P over wide area links. Of those five hundred seventy six bytes: twenty four bytes are protocol header — twenty bytes of standard I P header plus a small allowance for options or upper layer encapsulation — and five hundred fifty two bytes carry actual user data. Per packet: five hundred seventy six bytes shipped, five hundred fifty two of them are real information. Packet level efficiency: five hundred fifty two divided by five hundred seventy six, about ninety five point eight three percent. Compare that to the A T M cell — eighty eight point seven percent. The I P packet is more efficient at the packet level because the header is fixed at twenty four bytes regardless of how big the payload is. The bigger the packet, the smaller the header looks proportionally. Already, before we even count tail waste, we are saving seven points of efficiency.

4. 4. Map the POS/PPP stream continuously across C-4 boundaries

   

   Part a — packets per frame.

   The standard C-4 client container is 2,340 bytes per frame.

   Each packet: five hundred seventy six bytes.

   2,340/576=4.0625; this is a long-run phase ratio, not a per-frame packing quota.

   A PPP frame/PDU may cross a Higher Order VC boundary; do not floor each STM frame.

   A continuous conditional stream averages 4.0625 PDUs per STM frame; there is no fixed four-complete-PDU quota.

   One C-4 frame carries 4×576+36 bytes; those 36 bytes can begin the next boundary-crossing PDU.

   There is no recurring 18-byte unused tail; with the correct C-4, the arithmetic remainder would be 36 bytes.

   PDU and ATM cell streams may cross frame boundaries; per-frame integer-unit comparison is not standard mapping.

   Standard mappings have neither recurring 43-byte ATM nor 18-byte IP tail waste; the ledger counts framing/PDU fields and traffic mix.

   Part b — user data bits per frame.

   In the conditional problem model, each 576-byte PDU unit carries 552 stated-user bytes.

   Conditional user bits per PDU are correctly 552×8=4,416.

   Continuous C-4 mapping averages 2340×8×552/576=17,940 stated-user bits per STM frame.

   Narration transcript

   Part a — packets per frame. Payload area: two thousand three hundred twenty two bytes. Each packet: five hundred seventy six bytes. Two thousand three hundred twenty two divided by five hundred seventy six equals four point zero three one. Round down to four — packets are atomic, you cannot send half a packet. Four complete I P packets per S T M one frame. Total bytes occupied by those four packets: four times five hundred seventy six equals two thousand three hundred four bytes. Eighteen bytes of payload sit unused. Notice: just four atomic units fill the frame, compared to forty three A T M cells. Bigger pieces means fewer pieces means less tail waste — only eighteen wasted bytes versus forty three for A T M. Part b — user data bits per frame. Each packet carries five hundred fifty two bytes of user data. Five hundred fifty two times eight equals four thousand four hundred sixteen user bits per packet. Four packets per frame times four thousand four hundred sixteen — that is seventeen thousand six hundred sixty four bits of actual user information per frame.

5. 5. Calculate conditional user-rate and line-efficiency upper bounds

   

   Part c — efficiency.

   Conditional zero-extra-overhead line efficiency is 17940/19440=143.52/155.52≈92.284%; 90.87% comes from the wrong reset model.

   D32's corrected conditional AAL1 upper bound is 85.395%; compare only under stated, like-for-like service boundaries.

   Where did the savings come from?

   Two places.

   The conditional ledger's stated non-user share is 24/576≈4.167%; it is not all a universal IP header.

   ATM is a 5-byte header+48-byte information field; the extra 1 byte exists only under the AAL1 non-P condition.

   Fixed-overhead amortization is one effect; end-to-end efficiency also depends on MTU, fragmentation, stuffing, loss, and application semantics.

   Standard continuous C-4 mappings have neither recurring IP nor ATM tail waste.

   Part d — data rate.

   The conditional long-run average is 17,940 stated-user bits per 125 µs.

   The conditional upper-bound rate is 17940/125 µs=143.52 Mbit/s.

   D32's corrected conditional AAL1 bound is 132.806 Mbit/s; D33's class bound is 143.52 Mbit/s, while actual POS delivery depends on PPP/application overhead.

   The STM-1 line rate is the same, but mapping and service overhead differ; delivered user rate needs its own ledger and measurement.

   Narration transcript

   Part c — efficiency. Seventeen thousand six hundred sixty four user bits divided by nineteen thousand four hundred forty total bits equals zero point nine zero eight seven, or ninety point eight seven percent. Compare that to A T M's eighty three point one seven percent — an improvement of seven point seven percentage points. Where did the savings come from? Two places. One: the I P header is twenty four bytes per five seventy six byte packet — about four point one seven percent. A T M was six bytes per fifty three byte cell — about eleven point three percent. Bigger packets simply spread the header over more user bytes. Two: only eighteen bytes of payload tail wasted, instead of forty three for A T M. Part d — data rate. Each frame carries seventeen thousand six hundred sixty four user bits in one hundred twenty five microseconds. Seventeen thousand six hundred sixty four divided by one hundred twenty five microseconds equals one hundred forty one point three one two megabits per second. Compared to A T M's one hundred twenty nine point three four four — I P delivers about twelve more megabits per second of useful data through the same one fifty five megabit per second pipe. Same line rate, same overhead, but the user gets more.

6. 6. Gate actual goodput on PPP, MTU, QoS, and protection

   

   Three takeaways from this exercise.

   Larger PDUs may amortize fixed overhead; efficiency/latency also depends on MTU, fragmentation, scheduler, loss, and retransmission.

   If path MTU and encapsulation allow, 1,500-byte datagrams may be carried; larger size alone does not guarantee higher end-to-end efficiency.

   A packet's serialization can delay competing traffic without scheduling/preemption; queue and offered load also matter.

   Small fixed ATM cells set serialization granularity; ATM/IP design history and delay behavior should not be reduced to one cause.

   Standard continuous byte-stream mapping measures framing/stuffing/padding and traffic utilization, not a discarded frame tail.

   There is no recurring 43-byte ATM or 18-byte IP waste; both streams continue their boundary phase.

   The client container is 2,340 bytes, but standard POS framing does not reset PDUs at each frame boundary, so divisibility is unnecessary.

   Packet sizes follow protocol, MTU, application, and encapsulation constraints; avoid a categorical ‘no network’ claim.

   If D34 mixes 53-byte ATM cells with hypothetical 77-byte units, the 77-byte unit is not an ATM cell and its mapping/boundary assumptions need a separate audit.

   Heterogeneous-traffic efficiency depends on mapping, encapsulation, idle share, and service-boundary definition as well as unit mix.

   Same frame, different fillings — the answers keep getting more interesting.

   Narration transcript

   Three takeaways from this exercise. One: bigger packets are more efficient — at the cost of latency predictability. I P packets up to fifteen hundred bytes can flow through this same frame, pushing efficiency even higher. But a single big packet hogging the line means a voice call has to wait its turn. A T M chose small fixed cells specifically to keep voice latency low; I P chose variable larger packets specifically because data flows benefit from amortizing the header. Two: the unused payload tail tells you how good the size match is. Forty three bytes wasted with A T M, eighteen bytes wasted with five seventy six byte I P. If you happened to pick a packet size that exactly divides two thousand three hundred twenty two, the tail goes to zero. Four hundred fourteen byte packets, for example — but no real network uses arbitrary numbers like that. Three: in the next video we will mix two packet sizes in the same frame — fifty three byte A T M cells alongside seventy seven byte cells. We will see how the answer changes when the payload is heterogeneous, and which configuration squeezes the most user data out of the same nineteen thousand four hundred forty bits. Same frame, different fillings — the answers keep getting more interesting.

Source video: Communication Basics #33 Worked Example: STM-1 + 576-byte IP Packets — 90.87% Real Data (7:57)