Networking Fundamentals and Protocols Questions

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
Over the life of a connection, TCP's congestion window grows exponentially in slow start, switches to growing linearly in congestion avoidance once it approaches a known safe ceiling, and reacts to loss with fast retransmit and fast recovery rather than always restarting from scratch.

Structured elaboration

1. Slow start: the connection begins with a small congestion window (historically 1 segment; modern stacks start higher, commonly around 10 segments per RFC 6928) and roughly DOUBLES the window every round trip, since each of the ACKs for the previous batch triggers sending two new segments. This continues until either loss occurs, or the window reaches a threshold called ssthresh (slow start threshold), at which point the sender switches strategies.
2. Congestion avoidance: once at or above ssthresh, growth switches from exponential to roughly linear (classically, additive increase of about one segment per round trip), a much more cautious probe for additional capacity.
3. Fast retransmit: if the sender sees three duplicate ACKs (the receiver repeatedly acknowledging the same byte, implying a specific segment is missing but LATER data did arrive), it retransmits the missing segment immediately, without waiting for the retransmission timer to expire, since three duplicate ACKs is strong, specific evidence of loss rather than simple reordering.
4. Fast recovery: after a fast retransmit, rather than collapsing all the way back to slow start, ssthresh is set to about half the current window, and the window itself is set near that halved value, so the sender doesn't have to re-earn all its previous progress from a window of one segment; it resumes near where it estimates the path can actually sustain.

Worked example
Picture a connection whose window has grown to 64 segments in flight when a single segment is lost and detected via three duplicate ACKs (not a full timeout). Fast retransmit resends the missing segment immediately. Fast recovery sets ssthresh to roughly 32 (half of 64) and the window to near that value, then resumes congestion avoidance's linear growth from there, rather than collapsing to slow start's small initial window and doubling all the way back up. Contrast this with a RETRANSMISSION TIMEOUT (no duplicate ACKs arrived at all, meaning the loss was severe enough that the whole flight of data went missing): that's a much stronger loss signal, and the sender resets ssthresh to half the current window but drops the actual window all the way back to slow start's minimum, since a timeout implies the path may be far more broken than a few duplicate ACKs would suggest.

Trade-offs & pitfalls
It's a common mistake to say TCP always halves its window on any loss and moves on; a full retransmission timeout is treated far more conservatively (full reset to slow start) than a fast-retransmit-detected loss (a much gentler recovery), because the ABSENCE of any duplicate ACKs at all is itself informative: it suggests either a much larger loss event or a badly congested/broken path, not just one unlucky dropped segment.

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
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.

Direct answer
The UDP header is deliberately minimal, just four fields: source port, destination port, length, and checksum, and it provides no reliability, no ordering, and no flow or congestion control at all. The checksum is optional over IPv4 (it can be all-zeros to mean "not computed") but MANDATORY over IPv6, since IPv6 dropped the network-layer checksum that IPv4 had, leaving UDP's checksum as the only integrity check left covering the payload for that traffic.

Structured elaboration

• Source port (16 bits): the sending application's port, allowing a reply to be addressed back to the right process; can legitimately be zero if no reply is expected.
• Destination port (16 bits): identifies which application on the receiving host should get the datagram.
• Length (16 bits): the total length of the UDP header plus payload, in bytes, this is how a receiver knows where the datagram actually ends (UDP has no separate "end of message" marker otherwise).
• Checksum (16 bits): a checksum computed over a pseudo-header (which includes the source/destination IP addresses, borrowed conceptually from the IP layer to catch certain misdelivery errors) plus the UDP header and payload.

Over IPv4, the sender is technically permitted to skip computing the checksum entirely, since IPv4 packets already carry a header checksum which catches SOME corruption, though notably NOT payload corruption. Over IPv6, sending a UDP checksum is mandatory, precisely because IPv6 has no header checksum of its own at all, so UDP's checksum became the last line of defense for detecting corruption anywhere in the packet.

Worked example
If corrupted UDP payloads are reaching an application in production despite the checksum being enabled, that's actually a meaningful signal about WHERE the corruption is happening: a valid checksum plus corrupted payload data can only mean the corruption happened AFTER the checksum was computed and BEFORE the packet was actually transmitted onto the wire (for instance, in host memory, in a buggy driver, or in hardware), or that checksum offloading to the NIC is misconfigured or buggy (many NICs compute the checksum in hardware rather than the OS, and a broken offload implementation can silently produce or accept bad checksums). It would NOT typically indicate ordinary in-transit bit-flip corruption, since that's exactly the class of error the checksum exists to catch and reject.

Trade-offs & pitfalls
The 16-bit checksum, while better than nothing, is not cryptographically strong and won't catch every possible corruption pattern, especially certain kinds of systematic bit errors; applications with strict data-integrity requirements over UDP (like some real-time media or gaming protocols) often layer their own additional integrity or authentication checks on top rather than relying on the UDP checksum alone.