Networking Fundamentals and Protocols Questions

Direct answer
Encapsulation is the process of wrapping data in a new header (and sometimes trailer) as it moves down the protocol stack, and stripping those headers back off as it moves up the stack on the receiving side. Each layer only understands its own header; it treats everything handed to it by the layer above as an opaque payload.

Structured elaboration
Follow a browser's HTTP request to a web server, header by header, going down the sender's stack:

1. Application layer: the browser produces an HTTP request (method, path, headers, body).
2. Transport layer: TCP wraps that request in a TCP segment, adding a header with source port, destination port, sequence number, acknowledgment number, and flags. The whole HTTP request becomes the segment's payload.
3. Network layer: IP wraps the TCP segment in an IP packet, adding a header with the source IP address and destination IP address. The TCP segment becomes the packet's payload.
4. Data link layer: Ethernet wraps the IP packet in a frame, adding a header with the source MAC address and destination MAC address (and a trailer with a frame check sequence for error detection). The IP packet becomes the frame's payload.
5. Physical layer: the frame is converted to bits and transmitted as electrical, optical, or radio signals.

On the receiving side, decapsulation runs in exactly the reverse order: the physical layer recovers bits into a frame, the data link layer strips the Ethernet header/trailer and hands the IP packet up, the network layer strips the IP header and hands the TCP segment up, the transport layer strips the TCP header and hands the HTTP request up, and the application layer finally sees the original request.

Worked example
Concretely, by the time the original HTTP request bytes reach the wire, they are surrounded by four layers of header (ignoring the physical layer, which isn't a header at all): [Ethernet header][IP header][TCP header][HTTP request bytes][Ethernet trailer]. Each intermediate device on the path (a switch, a router) only needs to look at the headers relevant to its own layer: a switch reads the Ethernet header to decide which port to forward the frame out of; a router strips the Ethernet framing entirely, reads the IP header to decide the next hop, and re-wraps the same IP packet in a NEW Ethernet frame addressed to the next hop's MAC address. The TCP header and the HTTP payload never change as the packet crosses the network; only the Layer 2 framing gets rewritten at each hop.

Trade-offs & pitfalls
The most common confusion is expecting the MAC addresses in the Ethernet header to stay constant end-to-end, they don't. Only the IP addresses (Network layer) stay constant from source to destination; the MAC addresses (Data Link layer) change at every hop, because Ethernet framing is only meaningful on a single link, not across the whole path.

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
For a WAN replication job stuck at 20% of theoretical throughput, walk the transport-layer stack in this order: congestion-control behavior first (is loss even happening, and if so is the algorithm reacting sensibly), then window sizing relative to the path's bandwidth-delay product, then socket buffers, then NIC-level settings, since each of these can independently cap throughput and the cheapest checks come first.

Structured elaboration

1. Congestion-control algorithm and loss: check whether the connection is experiencing any packet loss at all (via retransmit counters, ss -i's retrans field). If there's meaningful loss and the algorithm is a loss-based one like Cubic, and the path has ANY non-congestive baseline loss (common on long WAN paths), the algorithm may be needlessly throttling itself; switching to BBR is a plausible fix here specifically because it doesn't over-react to non-congestive loss the way Cubic does.
2. Window size versus bandwidth-delay product: compute the path's bandwidth-delay product (bandwidth times round-trip time) and compare it to the connection's actual window (ss -i's cwnd and the negotiated window scale). If the window can never grow large enough to cover the bandwidth-delay product, no amount of congestion-control tuning will help, the connection is fundamentally window-limited, not congestion-limited.
3. Socket buffer sizing: even with window scaling negotiated, if the OS's actual send/receive socket buffers (net.ipv4.tcp_wmem/tcp_rmem on Linux) are capped below what the window scale option would otherwise allow, the effective window is capped at the smaller of the two, check both.
4. NIC-level settings: segmentation/offload settings (TSO/GSO/LRO) and interface MTU (Maximum Transmission Unit) affect how efficiently the CPU can push bytes onto the wire; a misconfigured or disabled offload setting can bottleneck a fast link at the CPU rather than the network itself, worth ruling out especially if CPU utilization on the sending host is unexpectedly high relative to the achieved throughput.

Worked example
Suppose the link is rated at 1 Gbps with a 200ms round-trip time. The bandwidth-delay product is 1e9 bits/s times 0.2s = 2e8 bits = 25,000,000 bytes (25 MB). If the connection's actual window, even after scaling, tops out at 5 MB (one-fifth of the required 25 MB), the connection can never exceed roughly one-fifth of the link's rated throughput, which lines up suspiciously well with an observed 20%. That's the single most likely explanation to check FIRST, since it directly predicts the exact ratio being observed, before assuming something more exotic like a congestion-control mismatch.

Trade-offs & pitfalls
It's tempting to jump straight to "switch congestion-control algorithms" as the fix, but that's the wrong first move if the real limiter is window size: no algorithm change fixes a window that's structurally too small for the path's bandwidth-delay product. Always compute the bandwidth-delay product FIRST and check whether the achieved throughput lines up with a window-limited explanation before reaching for an algorithm change.

Direct answer
A duplicate ACK is the receiver re-acknowledging the same byte offset it already acknowledged, which happens when a later, out-of-order segment arrives before the one actually missing; three duplicate ACKs in a row is treated as strong enough evidence of real loss to trigger an immediate fast retransmit, without waiting for the slower retransmission timer.

Structured elaboration
Normally, each ACK acknowledges progressively more data as segments arrive in order. If segment N is lost but segment N+1 arrives (out of the expected order relative to what the receiver is still waiting for), the receiver can't advance its cumulative ACK past the end of segment N-1, so it re-sends an ACK for the SAME byte offset it already acknowledged, that's the duplicate ACK. One or two duplicate ACKs are common and unremarkable (ordinary, brief reordering happens on real networks); but THREE duplicate ACKs in a row is treated as a strong enough signal that data is genuinely missing (not just briefly reordered) to justify retransmitting immediately, well before the (much slower) retransmission timeout would otherwise fire.

Distinguishing genuine loss from simple reordering, in practice: sustained duplicate ACKs (three or more, continuing as MORE out-of-order segments keep arriving) point to real loss, since a purely reordering event typically self-resolves within one or two duplicate ACKs once the delayed segment catches up. A pattern of isolated single or double duplicate ACKs that stop on their own, with no retransmission ultimately needed, points to reordering rather than loss; TCP's own reordering-tolerance thresholds (adjacent to, but distinct from, PAWS: Protect Against Wrapped Sequence numbers) exist specifically to avoid triggering a fast retransmit on every minor reordering event.

Worked example
A sender transmits segments carrying bytes 1000-1500, 1500-2000, 2000-2500, and 2500-3000. If the segment carrying 1500-2000 is lost but the other three arrive, the receiver sends: ACK 1500 (for the first segment, normal), then ACK 1500 again upon receiving 2000-2500 (a duplicate, since 1500-2000 is still missing), then ACK 1500 again upon receiving 2500-3000 (a second duplicate). On the THIRD duplicate ACK for 1500, the sender's fast retransmit fires and it resends the 1500-2000 segment immediately, rather than waiting for its retransmission timer (which, per the RTO calculation, could be tens to hundreds of milliseconds longer) to expire.

Trade-offs & pitfalls
The right mitigation depends entirely on which cause is confirmed: if it's genuine loss, the useful levers are addressing the actual loss source (a congested link, a flaky physical connection) or, at the transport layer, ensuring SACK (Selective Acknowledgment) is enabled so only the truly missing segment gets resent. If it's reordering (for instance, from a load balancer or ECMP path hashing packets across multiple physical paths with slightly different latencies), the fix is architectural (favor flow-based hashing that keeps a single connection's packets on one path) rather than anything TCP-level, since TCP is already tolerating ordinary reordering correctly; treating a reordering pattern as loss and "fixing" the transport layer for it addresses the wrong layer.

Direct answer
The OSI model splits network communication into seven layers, each handing off a well-defined unit of work to the layer above and below it: Physical, Data Link, Network, Transport, Session, Presentation, and Application. Knowing which layer a protocol or symptom belongs to lets you reason about failures systematically instead of guessing.

Structured elaboration

The mnemonic that matters more than memorizing names is the DIRECTION of responsibility: each layer only needs to trust the layer directly below it to deliver its unit of data, and it only exposes a clean interface to the layer above. That's what lets a Transport-layer protocol like TCP work identically over Ethernet, Wi-Fi, or a VPN tunnel: it never needs to know which Layer 1/2 technology is underneath.

Worked example
Say a user reports "the site is down." Layer-by-layer reasoning turns that vague complaint into a specific hypothesis:

• Physical/Data Link symptom: the NIC shows no link light, or ip link reports the interface as DOWN a cable or switch-port problem.
• Network layer symptom: ping to the server's IP times out but the local gateway responds a routing problem somewhere between here and there.
• Transport layer symptom: ping succeeds but a TCP connection to the port hangs or resets a firewall, a service that isn't listening, or a transport-level issue.
• Application layer symptom: the TCP connection completes but the HTTP response is an error or garbage the service is up but misbehaving.

Each of these is a different team, a different fix, and a different urgency. That's the actual payoff of the model: it turns "the site is down" into "which layer, which evidence."

Trade-offs & pitfalls
The OSI model is a teaching and troubleshooting framework, not how real stacks are literally implemented. Session and Presentation are rarely separate pieces of code in modern systems; TLS, for instance, is commonly described as "sits between Transport and Application" rather than cleanly as Layer 6. Don't over-fit a real symptom to exactly one layer: a firewall dropping SYN packets looks like a Transport-layer symptom (connection never establishes) but the actual cause and fix live at a security-policy layer that OSI doesn't model at all.