Networking Fundamentals and Protocols Questions

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
The end-to-end principle says that a function like reliability, error checking, or encryption should generally be implemented at the ENDPOINTS of a communication, not in the network in between, because only the endpoints have enough context to do it completely and correctly; anything the network attempts to do on the endpoints' behalf is, at best, redundant, and often incomplete.

Structured elaboration
The classic argument: even if a network device implements reliable delivery for its OWN hop (say, a link-layer retransmission scheme), the endpoints STILL need their own end-to-end reliability check, because failures can occur anywhere along the full path, including at the endpoints themselves (a corrupted disk write, an application bug), that no single intermediate hop's reliability mechanism can catch. Since the endpoints need to implement the full check anyway to cover the whole path, the intermediate hop's partial version becomes pure extra cost (complexity, latency, resource use) with no corresponding gain in actual end-to-end correctness. This is exactly the reasoning behind TCP's own design: reliability (retransmission, checksums) lives at the TRANSPORT layer, running on the two endpoints, not distributed piecemeal across every router the packet crosses.

Worked example
A case where following the end-to-end principle strictly is clearly the right call: end-to-end encryption. If confidentiality were instead implemented hop-by-hop (each link encrypting its own segment separately, decrypting and re-encrypting at every intermediate device), every single intermediate device becomes a point where the data is available in plaintext, and a single compromised or misconfigured hop breaks confidentiality for the WHOLE path. Only the endpoints encrypting directly to each other, with intermediate devices never possessing the ability to decrypt at all, gives a security guarantee that doesn't depend on trusting every device along the way.

A case where placing a function in an INTERMEDIATE device is justified, despite the end-to-end principle's default preference: a link with an unusually high, characteristic error rate (some wireless or satellite links) benefits from LOCAL link-layer retransmission on just that one hop, because retransmitting a single lost bit-pattern on the actual lossy hop is far cheaper (both in latency and in bandwidth) than always waiting for a full end-to-end retransmission across the ENTIRE path whenever that one link drops something. This doesn't replace the endpoints' own end-to-end mechanism (which must still exist to catch failures anywhere else along the path); it's a legitimate LOCAL optimization layered underneath it, not a substitute for it.

Trade-offs & pitfalls
The end-to-end principle is a strong DEFAULT, not an absolute law; the mistake is either applying it dogmatically (refusing any intermediate optimization, even ones that provide a real, complementary performance benefit on a specific problematic hop) or abandoning it too readily (letting the network take over a correctness-critical function like encryption or reliability entirely, on the mistaken assumption that "the network already handles that").

Direct answer
When packets are genuinely just arriving out of order (not lost), TCP has built-in tolerance thresholds so it doesn't mistake brief reordering for loss and trigger an unnecessary fast retransmit; PAWS (Protect Against Wrapped Sequence numbers) is a related but distinct mechanism that uses timestamps to detect and discard old, delayed duplicate segments from earlier in a long-running high-speed connection.

Structured elaboration
Modern TCP stacks track how far "out of order" a segment can arrive (measured in either packet count or time) before treating it as evidence of real loss rather than harmless reordering; Linux, for instance, exposes tunables around reordering tolerance that adapt based on the connection's OWN observed reordering history, rather than using one fixed global threshold for every connection. A connection on a path known to reorder packets occasionally (some multi-path or load-balanced routes do this by design) can raise its own tolerance so ordinary reordering doesn't repeatedly trigger unnecessary fast retransmits.

PAWS solves a different, narrower problem specific to very fast connections: on a high-bandwidth link, the 32-bit TCP sequence number space can actually WRAP AROUND within the lifetime of a single connection (send enough gigabytes fast enough and you'll reuse sequence numbers that were valid earlier in the SAME connection). PAWS uses the TCP timestamp option, present on nearly every modern connection, to disambiguate: if a segment arrives whose sequence number would otherwise look valid but whose timestamp is clearly older than the most recent one seen, it's recognized as a stale duplicate from earlier in the connection (possibly delayed en route) and discarded, rather than being misinterpreted as new data that happens to reuse an old sequence number.

Worked example
On a path prone to reordering (say, traffic load-balanced per-packet, not per-flow, across multiple physical links with slightly different latencies), segments can regularly arrive a few positions out of order without any data actually being lost. If TCP's reordering tolerance is too strict, this triggers spurious fast retransmits and duplicate-ACK-driven congestion-window reductions on a connection that never actually experienced loss, hurting throughput for no real reason. An application-level (rather than pure TCP-level) fallback in genuinely reordering-prone environments is to add its OWN sequencing at the application layer, buffering and reassembling out-of-order application messages itself, so the transport layer's retransmission machinery isn't repeatedly triggered by ordinary path-level reordering it can't avoid.

Trade-offs & pitfalls
Raising reordering tolerance too aggressively to avoid spurious retransmits comes at a real cost: on a connection that IS actually experiencing loss (not reordering), a higher tolerance delays how quickly that genuine loss gets detected and retransmitted, directly trading recovery latency for false-positive avoidance. There's no free lunch here; the right tolerance setting depends on knowing, for a specific path, whether reordering or loss is the dominant failure mode.

Direct answer
Bufferbloat happens when routers or switches along a path have excessively large buffers that queue packets during congestion instead of dropping them, which keeps loss low but lets queuing delay grow essentially unbounded, adding latency and jitter that TCP's own congestion control never gets a clear enough signal to react to. Active Queue Management algorithms like fq_codel counteract it by proactively dropping or marking packets BEFORE the queue grows large, restoring a timely loss signal.

Structured elaboration
A classic loss-based congestion-control algorithm relies on packet loss (or an explicit congestion mark) as its primary "back off" signal. If a device's buffer is very large, it can absorb a burst of excess traffic by queuing it rather than dropping it, so loss never actually happens, but every packet sitting in that oversized queue now experiences extra delay waiting its turn. Ironically, a device built to be MORE forgiving (bigger buffer, less loss) ends up making the user experience WORSE (much higher and more variable latency) precisely because it hides the congestion signal the sender needs to slow down.

fq_codel (Fair Queuing with Controlled Delay) attacks this from two angles: "fair queuing" gives each active flow its own small queue so one bulk-transfer flow can't monopolize the buffer and starve a latency-sensitive flow (like a video call) sharing the same link; "controlled delay" tracks how long packets are actually sitting in the queue, and once a packet has been queued longer than a target delay (commonly around 5ms), it starts dropping packets to force the responsible flow's congestion control to back off, well before the queue grows large enough to cause serious latency.

Worked example
On a home internet connection with a large, un-managed buffer at the router, a single large upload (like a cloud backup) can push queuing delay from a normal few milliseconds up to several hundred milliseconds or more, which is directly noticeable as a video call over the same connection becoming choppy or laggy, even though no packets for the video call are actually being dropped, they're just sitting in a queue behind the bulk upload's traffic for hundreds of milliseconds. Enabling fq_codel on that router's egress queue caps how long any packet can wait, keeping the video call's latency low even while the bulk upload continues in the background.

Trade-offs & pitfalls
Bufferbloat is easy to misdiagnose as "the link doesn't have enough bandwidth" when the real problem is excess, unmanaged queuing delay on a link that has PLENTY of bandwidth; the fix (AQM, not more bandwidth) is the opposite of what a naive read of "things feel slow" would suggest. A useful diagnostic: latency under load (with a saturating background transfer running) that's dramatically higher than idle-latency is the signature of bufferbloat, not a raw throughput problem.

Direct answer
A graceful close is a symmetric exchange where each direction of the connection is shut down independently with its own FIN/ACK pair; an abrupt close (RST) tears down both directions immediately and without acknowledgment, discarding any data still in flight.

Structured elaboration
Graceful close, the normal case: the side that's done sending data sends a FIN. The other side ACKs it and moves to CLOSE_WAIT (it can still send its own data; only ONE direction has closed so far). When that side is also done, it sends its own FIN, the original side ACKs it, and both directions are now closed. Because it takes a FIN and an ACK in EACH direction, a full graceful close is normally four messages (though the middle ACK and FIN are frequently combined into one segment in practice), and the side that sent the last ACK enters TIME_WAIT.

Abrupt close via RST: either side can send a RST at any point to say "this connection is invalid, stop immediately," with no ACK expected and no guarantee that data already sent (or in flight) will be delivered or acknowledged. A RST is what you see when a process crashes and the OS cleans up its sockets, when data arrives for a port nothing is listening on, or when an application deliberately aborts a connection instead of finishing a clean handshake-of-goodbyes.

Simultaneous close is the edge case where BOTH sides send a FIN before either has received the other's FIN. Both sides transition through a CLOSING state (rather than one going through FIN_WAIT and the other CLOSE_WAIT) before eventually reaching TIME_WAIT once both FINs are acknowledged. It's rare, but it's why the TCP state machine has a CLOSING state at all: it exists specifically for this race.

Worked example
A RST during the handshake itself, before a connection is even established, means something different from a RST on an established connection: it almost always means nothing is listening on that port (or a firewall/security-group is actively rejecting rather than silently dropping). This is one of the fastest network diagnostics available, a connection refused instantly (RST) tells you the path and host are reachable but the service isn't there, whereas a connection that hangs and eventually times out with no RST tells you the packet may be silently dropped somewhere in the path, a materially different failure to chase down.

Trade-offs & pitfalls
Asymmetric routing can produce a half-open connection that looks alive on one side even after the other side has actually closed: if the FIN from one side never arrives (dropped along an asymmetric or otherwise broken return path), that side can sit in FIN_WAIT or the other side in ESTABLISHED indefinitely from its own perspective, believing the connection is fine when it's not. Keepalive probes exist specifically to eventually detect and clear out this class of half-open zombie connection, since neither side's own state machine will notice on its own.