Networking Fundamentals and Protocols Questions

Direct answer
Selective Acknowledgment (SACK) lets a receiver tell the sender exactly which non-contiguous blocks of data it has ALREADY received, so after a loss the sender only has to retransmit the specific missing segment(s), not everything that came after it.

Structured elaboration
Without SACK, TCP uses cumulative acknowledgment: an ACK only confirms "I have received everything up through this byte, contiguously." If segment 3 of a 10-segment flight is lost but segments 4 through 10 all arrive fine, the receiver can only ACK up through the end of segment 2, it has no way to tell the sender "I actually already have 4 through 10, I'm just missing 3." A sender using only cumulative ACKs, upon detecting the loss, may end up retransmitting segments 3 through 10 (everything the receiver hasn't cumulatively acknowledged), even though 4 through 10 were never actually lost.

With SACK enabled (negotiated via a permitted option in the handshake, then carried on subsequent ACKs), the receiver's ACK can include SACK blocks, explicit ranges of sequence numbers it holds that are NOT contiguous with the main acknowledged run, in the example above, a SACK block spanning segments 4 through 10. Now the sender knows precisely that only segment 3 needs retransmitting.

Worked example
Say a sender has segments with sequence ranges [1000-1500), [1500-2000), [2000-2500), ... up to [4500-5000), and segment [2000-2500) is lost in transit while everything else arrives. Without SACK: the receiver's ACKs stay pinned at ack=2000 (the last contiguous byte received) even as segments up through 5000 keep arriving; the sender, upon detecting the loss (via duplicate ACKs all saying ack=2000), knows only that SOMETHING after 2000 needs resending and, in older/naive implementations, could resend everything from 2000 onward. With SACK: the same duplicate ACKs at ack=2000 now also carry a SACK block like sack=2500-5000, telling the sender explicitly that only the single segment [2000-2500) is actually missing, so it retransmits exactly that one segment and nothing else.

Trade-offs & pitfalls
SACK is most valuable on connections with a large amount of data in flight (a large window relative to segment size) and where losses are isolated rather than in a solid burst, since that's exactly the scenario where "retransmit everything after the gap" wastes the most bandwidth compared to "retransmit only the gap." On a connection with a tiny window, or where an entire flight is lost at once (nothing left to selectively acknowledge), SACK provides little advantage.

Direct answer
IPv4 fragmentation splits a packet too large for a link into smaller pieces, each carrying enough header information (Identification, Flags, Fragment Offset) for the destination to reassemble the original packet, and it can fail in several distinct ways, a missing fragment, overlapping fragments, or a reassembly timeout, any of which prevents the original packet from ever being reconstructed.

Structured elaboration
Three IPv4 header fields work together to make fragmentation and reassembly possible:

• Identification: a 16-bit value the ORIGINAL packet is stamped with; every fragment of that same original packet carries the SAME Identification value, so the receiver knows which fragments belong together.
• Flags: includes the "Don't Fragment" (DF) bit, which tells routers along the path NOT to fragment this packet (instead, if it's too large for the next link, they must drop it and report the problem back via Internet Control Message Protocol, ICMP), and the "More Fragments" (MF) bit, set on every fragment except the LAST one, telling the receiver more pieces are still coming.
• Fragment Offset: a 13-bit field (in units of 8 bytes) indicating WHERE in the original packet's payload this particular fragment's data belongs, letting the receiver reassemble fragments that might arrive out of order.

The receiver buffers incoming fragments sharing the same Identification (and same source/destination address pair and protocol) until either all fragments have arrived (the last one identified by MF=0) and can be stitched back together in Fragment-Offset order, or a reassembly timer expires first.

Worked example
If a fragment carrying offset 0-1000 and another carrying offset 1000-2000 arrive, but the fragment that should have covered 2000-2500 (the actual final piece, with MF=0) never arrives, perhaps dropped somewhere along the path, the receiver has no way to know reassembly is even complete; it will hold the two partial fragments in its reassembly buffer until its reassembly timeout (commonly around 30 to 60 seconds depending on the OS) expires, then discard them and the entire original packet is lost, even though 2 of its 3 pieces successfully arrived. Overlapping fragments (two fragments both claiming to cover the SAME offset range, but with different content) are treated with suspicion by modern stacks specifically because that pattern was historically exploited in fragmentation-based attacks (evading firewall inspection by presenting different content to the firewall's re-assembly logic than to the actual destination host's).

Trade-offs & pitfalls
Fragmentation is something you generally want to AVOID rather than rely on: it multiplies the chance of a single original packet failing to arrive (since ALL its fragments must arrive for it to be usable at all, a single lost fragment dooms the whole packet even if every other fragment made it), it's more CPU-expensive for receivers to reassemble than to simply process one appropriately-sized packet, and many network devices (especially older or security-focused ones) handle fragments inconsistently or drop them outright, treating fragmentation itself as suspicious traffic. This is exactly why Path MTU (Maximum Transmission Unit) Discovery exists: to let a sender learn the right packet size UP FRONT and avoid needing fragmentation at all.

Direct answer
QUIC achieves per-stream reliability and ordering without TCP's single shared sequence space by giving each logical stream its OWN independent sequence numbering and loss recovery, all multiplexed inside one UDP-based connection; a lost packet carrying data for stream A doesn't block already-arrived data for stream B from being delivered to the application, which is exactly the head-of-line blocking that a single TCP connection carrying multiple HTTP/2 streams suffers from.

Structured elaboration
Over plain TCP, HTTP/2 multiplexes many logical request/response streams onto ONE underlying TCP connection with ONE sequence-number space; TCP itself has no concept of "streams" at all, it just sees one ordered byte stream. If a single TCP segment is lost, TCP's in-order delivery guarantee means EVERY byte after that point, even bytes belonging to a completely different, otherwise-unaffected HTTP/2 stream, is held back until the lost segment is retransmitted and recovered. This is transport-level head-of-line blocking: the transport's OWN reliability guarantee (strict ordering) becomes a liability once a single connection is asked to carry multiple independent logical streams.

QUIC solves this by moving stream multiplexing INTO the transport layer itself, rather than layering it on top of a single ordered byte stream: each stream has its own sequence space and its own independent reliability/ordering guarantee, so a loss affecting one stream's data only blocks THAT stream's delivery, other streams' already-arrived data can be delivered to the application immediately, with no need to wait.

Worked example
Practically, building this on UDP (rather than trying to retrofit multi-stream awareness into TCP itself) was the pragmatic choice because TCP's behavior is deeply embedded in operating system kernels, network hardware, and middleboxes across the internet; changing TCP's fundamental semantics at that scale is far harder than building a new protocol on top of UDP, which is deliberately minimal and gives QUIC a mostly-blank slate to define its own semantics, while still being able to traverse the internet's existing UDP-forwarding infrastructure without needing every router and middlebox to understand the new protocol.

Trade-offs & pitfalls
This is a genuine, structural advantage for workloads with multiple independent logical streams sharing a connection (which is exactly the HTTP/2-and-later web-traffic pattern), but it isn't a free win for every workload: an application sending one single, purely sequential stream of data (like a straightforward large-file download) doesn't gain the same benefit from per-stream independence, since it only has one stream to begin with, the head-of-line-blocking problem QUIC solves specifically arises from MULTIPLE independent streams sharing one connection.

Direct answer
Flow control protects the RECEIVER from being overwhelmed by data it can't process fast enough; congestion control protects the NETWORK from being overwhelmed by more traffic than the path between sender and receiver can actually carry. They use different signals and different windows, and confusing them leads to fixing the wrong end of the problem.

Structured elaboration
Flow control is implemented via the receive window (often written rwnd): the receiver advertises, in every ACK, how many more bytes of buffer space it currently has available. If the receiver's application is slow to read data out of its socket buffer, the advertised window shrinks, telling the sender to slow down regardless of how healthy the network path is. This is purely an endpoint-to-endpoint negotiation; the network in between plays no role.

Congestion control is implemented via the congestion window (cwnd), a value the SENDER maintains based on inferred network conditions, growing during slow start and congestion avoidance, and shrinking sharply when loss (or, with explicit congestion notification, an ECN mark) signals that the path is overloaded. Crucially, the sender is never allowed to have more unacknowledged data in flight than the SMALLER of rwnd and cwnd, whichever is more restrictive wins.

Worked example
Consider a video-conferencing server pushing data to a client on a fast, low-latency corporate network with no packet loss anywhere on the path. If the client's own CPU is pegged and its application isn't draining its TCP receive buffer fast enough, throughput will stall even though the network itself has plenty of headroom, that's a rwnd (flow control) problem, and the fix is on the client (free up CPU, drain the socket faster), not on the network. Conversely, if the same server saturates a congested shared WAN link, cwnd will shrink due to loss even though the receiver's buffer is empty and eager for more data, that's a congestion-control problem, and the fix is either reducing the amount of data in flight or addressing the actual network bottleneck, not the receiver.

Trade-offs & pitfalls
Confusing the two leads to genuinely wrong fixes: tuning net.ipv4.tcp_rmem (receive buffer size, which affects flow control's rwnd) will do nothing for a connection that's actually congestion-limited, and conversely, tuning the congestion control algorithm won't help a connection that's flow-control-limited by a slow receiving application. The fastest way to tell them apart in practice: watch which window value (rwnd vs cwnd) is the SMALLER, limiting one during the stall, most modern TCP instrumentation (ss -i on Linux) exposes both.

Direct answer
IPv6 removed the ability for ROUTERS along the path to fragment a packet; only the ORIGINATING host may fragment an IPv6 packet, using a dedicated fragmentation extension header, which pushes the entire responsibility for correctly sizing packets (and reacting to Path MTU, Maximum Transmission Unit, Discovery feedback) onto the sender rather than sharing it with the network.

Structured elaboration
In IPv4, any router along the path could fragment a packet too large for its outgoing link (unless the Don't Fragment bit was set), a convenience that came at real cost: routers doing fragmentation work on the fly, and receivers having to reassemble fragments that could have been created by ANY device along the path, not just the sender. IPv6's designers removed this entirely: routers now MUST drop an IPv6 packet that's too large for the next link and send back an ICMPv6 "Packet Too Big" message reporting the link's MTU, rather than fragmenting it themselves. If the ORIGINATING host still needs to send data larger than the smallest MTU along the path, it must fragment the packet itself, before sending, using the IPv6 Fragment extension header (which carries the same conceptual information as IPv4's Identification/Flags/Offset fields, just in a dedicated extension header rather than baked into the main IP header).

Worked example
This design change makes Path MTU Discovery load-bearing in IPv6 in a way it wasn't strictly required to be in IPv4: since no device in the middle of the path can rescue an oversized packet by fragmenting it, a sender that doesn't properly discover and respect the path's minimum MTU will simply have its packets dropped along the way (with an ICMPv6 message reporting why, PROVIDED that message isn't itself being filtered somewhere, the classic PMTUD-blackhole failure mode). This is also why a middlebox in the middle of an IPv6 path is a materially different kind of obstacle than in IPv4: it cannot silently paper over an oversized-packet problem by fragmenting on the sender's behalf; it can only drop and (hopefully) report back.

Trade-offs & pitfalls
The IPv6 design trades away routers' ability to "fix" an oversized packet on the fly in exchange for a simpler, more predictable job for routers (never having to fragment) and a stronger incentive for senders to get Path MTU Discovery right in the first place, rather than relying on the network to quietly compensate for an oversized packet. The practical implication: if ICMPv6 "Packet Too Big" messages are filtered anywhere along an IPv6 path (the same class of misconfiguration that breaks IPv4 PMTUD), there is NO fallback fragmentation happening in the middle of the path to mask the problem, the failure is more absolute than the equivalent IPv4 case.