--- title: "TCP Can Receive Later Bytes While the Stream Still Waits on a Gap" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/tcp-cumulative-ack-sack-received-byte-gaps" last-updated: "2026-10-20" --- # TCP Can Receive Later Bytes While the Stream Still Waits on a Gap Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. TCP can receive and hold later bytes while an earlier missing range prevents ordered delivery of those later bytes. A cumulative ACK of 2000 can therefore coexist with a SACK block [3000,4000): the next expected sequence position is still 2000, while bytes 3000 through 3999 have been reported received. The two fields describe different parts of the same reception state. ## Ordered delivery and received ranges answer different questions Consider a TCP dataset transfer into a GPU environment. The receiving TCP can have useful data in its queue beyond a gap. Its application still needs the stream in order. Earlier contiguous data may already be available to the application; it is the later region that cannot be delivered ahead of the missing bytes. RFC 9293, the August 2022 TCP specification, defines an in-order byte-stream service. Each data octet has a sequence number. The cumulative acknowledgment identifies the next expected sequence position and covers the preceding sequence space. It does not enumerate received packets. Selective acknowledgment adds another view. RFC 2018, published in October 1996, defines SACK blocks for received, queued ranges beyond gaps without changing the cumulative ACK field's meaning. A report can therefore show additional reception while the cumulative frontier stays fixed. References: [R1](https://www.rfc-editor.org/rfc/rfc9293.txt), [R2](https://www.rfc-editor.org/rfc/rfc2018.html) ## Work ACK 2000 with SACK [3000,4000) Use an original hypothetical example in one direction of an established connection. All earlier stream bytes through sequence position 999 have arrived in order. The receiver initially expects 1000. There is no sequence-number wrap, and no SYN or FIN occupies the illustrated interval. SACK is permitted in this direction, the data fits the receiver's allowed range, and no bytes at or beyond 4000 are received. The notation [1000,2000) includes 1000 and excludes 2000. It contains 1000 data bytes, numbered 1000 through 1999. When that range has arrived contiguously, the receiver can report ACK 2000: position 2000 is next. Now stipulate that [2000,3000) has not arrived, but [3000,4000) has arrived and is held. The receiver can report ACK 2000 together with SACK [3000,4000). The SACK block's left edge names its first byte; its right edge is the position immediately after its last byte. It reports another 1000 received bytes without asserting receipt of the intervening 1000. Within the illustrated [1000,4000) span, 2000 distinct data bytes have arrived and 1000 remain missing. The span is 3000 bytes long, but its length is not the received-byte total. Nor can the receiver replace ACK 2000 with ACK 4000 merely because the highest held byte is 3999. The gap still starts at 2000. These intervals describe byte positions, not three stipulated packets or three application writes. Their interpretation does not depend on a particular segmentation. References: [R1](https://www.rfc-editor.org/rfc/rfc9293.txt), [R2](https://www.rfc-editor.org/rfc/rfc2018.html) ## A 1000-byte arrival can advance the ACK by 2000 Next, stipulate successful delivery of every byte in [2000,3000), with the queued [3000,4000) data still retained. The illustrated data now joins into [1000,4000), a contiguous 3000-byte range following the earlier stream. The next expected position becomes 4000, so the receiver can advance its cumulative ACK to 4000. Only 1000 new data bytes arrived in this last event. Yet the ACK advances from 2000 to 4000, covering 2000 sequence positions: the newly filled gap plus the 1000 later bytes already held. An ACK increment is therefore not a measurement of the latest packet's payload. Retention is essential to that result. Successful arrival of [2000,3000) would not, by itself, establish a contiguous range through 3999 if the receiver had meanwhile discarded [3000,4000). The example stipulates the resulting state, without assigning a recovery trigger or a completion time. References: [R1](https://www.rfc-editor.org/rfc/rfc9293.txt), [R2](https://www.rfc-editor.org/rfc/rfc2018.html) ## SACK reports reception without promising continued retention RFC 2018 makes SACK advisory. Sections 3 and 8 permit a receiver to discard data it previously reported in a SACK block; this is called reneging. A SACK report is useful evidence of reception, but it cannot make the later-retention assumption unnecessary. The option also need not list every queued range: section 4 notes that available option space can limit the blocks reported. A supplied SACK list should not automatically be treated as a complete inventory of the receiver's queue. Outside the stipulated example, ACK 2000 and that one SACK block alone do not establish that every byte in [2000,3000) is absent. References: [R2](https://www.rfc-editor.org/rfc/rfc2018.html) ## Decide which kind of progress the evidence establishes Suppose a transfer report says that 2000 bytes of this fictional 3000-byte span have reached the receiving TCP. Under the stated assumptions, that claim is compatible with ACK 2000 and SACK [3000,4000). A second claim that the application can already read the complete span in order does not follow: the middle 1000 bytes are still absent. Even after ACK 4000, application consumption remains a separate question. RFC 9293, section 3.8.6.2.2, explicitly describes received and acknowledged data that the user process has not yet consumed. A claim that the application has processed the dataset or committed it to durable storage therefore needs evidence from that application or storage boundary. For a buyer assessing a progress claim, preserve whether the supplied quantity describes distinct received byte ranges, the cumulative frontier or observed application completion. The same transfer can show different progress at those boundaries without a contradiction. This example establishes no throughput or physical-link diagnosis. Use the related window-and-RTT article for outstanding-data allowances and an ideal rate bound. Use the MTU-and-MSS article for packet byte budgets and application framing. Those calculations answer different questions from whether received ranges have joined into a contiguous stream. References: [R1](https://www.rfc-editor.org/rfc/rfc9293.txt) ## Bring an approved physical change into the cabling scope If the wider project includes approved physical connection work, Leviathan's structured cabling service can discuss installation, routing, dressing, labeling and agreed connection records using customer-furnished or separately sourced materials. The service and project-inquiry links below support that physical scope. Share the approved endpoints, assembly requirements, routes, appointed materials supplier and required handoff records. TCP behavior and application progress remain with the appointed network and application owners; the byte-gap example supplies education rather than authorization for live work. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [R1 — RFC 9293: Transmission Control Protocol (TCP), STD 7](https://www.rfc-editor.org/rfc/rfc9293.txt). Checked 2026-10-20. August 2022. Sections 2.2, 3.1 and 3.4 define ordered byte-stream service, the acknowledgment field and sequence-space progress. Section 3.8.6.2.2 distinguishes acknowledged reception from application consumption. The worked ranges are original stipulated examples. - [R2 — RFC 2018: TCP Selective Acknowledgment Options](https://www.rfc-editor.org/rfc/rfc2018.html). Checked 2026-10-20. October 1996. Sections 1–4 define permission, queued ranges and SACK block edges; sections 3 and 8 establish advisory SACK and possible receiver reneging. Used for acknowledgment meaning, without adopting recovery algorithms or performance claims. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Physical installation, routing, labeling and agreed connection records with customer-furnished or separately sourced materials. Applicable only when the project includes physical cabling work; TCP configuration and application evaluation have separate owners. ## Related Leviathan resources - [TCP window and RTT: why a faster port may leave an ideal rate bound unchanged](/articles/tcp-window-rtt-versus-network-line-rate) - [Ethernet MTU and TCP MSS: packet budgets and application data](/articles/ethernet-mtu-tcp-mss-application-payload) - [Structured cabling and fiber installation](/services/structured-cabling) - [Discuss approved physical connection work](/contact?service=structured-cabling&from=%2Farticles%2Ftcp-cumulative-ack-sack-received-byte-gaps) - [How Multipath TCP Reassembles One Byte Stream from Several Subflows](/articles/mptcp-subflow-mapping-single-byte-stream) ## Does the project include physical connection work? Share the approved endpoints, assemblies, routes, materials responsibilities and required connection records to discuss physical scope and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/tcp-cumulative-ack-sack-received-byte-gaps)