Exercises — UDP — header, use cases, checksum

L1.1 — The UDP header is 8 bytes, made of 4 fields, each 16 bits (16 bits = 2 bytes, and $4\times 2=8$). In order: Source Port, Destination Port, Length, Checksum (mnemonic SP-DP-LC).

L1.2 — Length counts header + data. The header alone is 8 bytes and is always present, so the smallest legal value is $8+0=8$, which corresponds to a datagram with an empty payload (0 data bytes).

L1.3 — In IPv4 the checksum is optional. A literal 0x0000 in the field is the reserved code meaning "no checksum was computed — do not verify." It does not mean "checksum is zero" (a genuine zero result is transmitted as 0xFFFF instead, freeing 0x0000 for this signal). In IPv6 you'd never see this, because there the checksum is mandatory.

L2.1 — Length $=8\text{ (header)}+20\text{ (data)}=28$ bytes = 0x001C.

L2.2 — Add normally first: $\text{0xF000}+\text{0x2000}=\text{0x11000}.$ That result needs a 17th bit (the leading 1), so it overflowed 16 bits. Carry-wrap: strip the top 1 (which is $\text{0x10000}$) and add it back to the low 16 bits: $\text{0x1000}+\text{0x0001}=\text{0x1001}.$ One's-complement sum $=\text{0x1001}$. Why bother wrapping? So the overflow carries information back in instead of being lost — that's what keeps the sum symmetric and inside 16 bits.

L2.3 — The transmitted checksum is the bitwise complement $\overline{x}$ (flip every bit) of the sum: $\overline{\text{0x3BCC}}=\text{0xC433}.$ (Check: 0x3BCC = 0011 1011 1100 1100; flip → 1100 0100 0011 0011 = 0xC433.) Transmitted checksum $=\text{0xC433}$.

L3.1 — Let $S$ be the one's-complement sum of all data words. The checksum transmitted is $\overline{S}$ (the bitwise complement, every bit flipped). The receiver re-adds every word plus the checksum: $S\oplus \oplus \overline{S}.$ In one's-complement arithmetic, a number added to its bitwise complement gives all ones: at every bit position exactly one of $S$, $\overline{S}$ has a 1 (they are opposites), so $x+\overline{x}=\text{0xFFFF}$ with no position empty. Getting 0xFFFF therefore means the sum the receiver rebuilt equals the sum the sender computed — the data is (probably) intact. Any single flipped bit breaks one column and the total is no longer all-ones. See One's complement arithmetic.

L3.2 — The checksum is a sum. Adding $+1$ to one word and $-1$ to another leaves the total unchanged ($+1-1=0$), so the re-computed sum still matches and the check passes — even though the data is corrupt. This is the fundamental weakness of a 16-bit additive checksum: errors can cancel. It catches most single-bit flips but is not a cryptographic guarantee.

L3.3 — IP delivers to a machine by its address, but a corrupted or misrouted address could deliver a datagram to the wrong host, and UDP's own header has no way to notice. By folding the IP addresses into the checksum (the pseudo-header), a wrong destination IP makes the checksum fail at the wrong receiver, so it drops the datagram. The IPv4 pseudo-header is 12 bytes, laid out as 16-bit words: $\text{Source IP (32 bits)}\mid \text{Destination IP (32 bits)}$ $\text{Zero pad byte (8)}\mid \text{Protocol = 17 (8)}\mid \text{UDP Length (16)}$ Note the zero pad byte sitting before the protocol number: the protocol is only 8 bits, but the checksum works on 16-bit words, so an all-zero byte is prepended to make protocol land in a clean 16-bit word (0x0011, since $17=\text{0x11}$). That pad byte is 0x00, so it contributes nothing to the sum — it exists purely for alignment. This is a deliberate layering "violation" — Transport peeking at IP addresses — accepted because misdelivery detection is worth it.

L4.1 — First map the symbols to the given words so nothing is unnamed: let $w_1=\text{0x4500}$, $w_2=\text{0xF6CB}$, $w_3=\text{0x0000}$. The figure above walks these exact steps: each labelled row is one line of this solution, and the coloured arrows mark the carry-wrap (teal) and the final complement (plum) so you can see which operation each transition is. Follow it top-to-bottom alongside the text.

• Add $w_1+w_2$ ($\text{0x4500}+\text{0xF6CB}$): $=\text{0x13BCB}$. Overflowed 16 bits (leading 1).
• Carry-wrap: drop the 1 (i.e. $\text{0x10000}$), add it back to the low word: $\text{0x3BCB}+\text{0x1}=\text{0x3BCC}$.
• Add $w_3$ ($+\text{0x0000}$): $\text{0x3BCC}+\text{0x0000}=\text{0x3BCC}$. No carry.
• Complement: $\overline{\text{0x3BCC}}=\text{0xC433}$ ← transmitted checksum (the plum arrow in the figure).
• Receiver check: re-add the running sum and the checksum: $\text{0x3BCC}+\text{0xC433}=\text{0xFFFF}$ ✓ all ones → accept.

L4.2 — Count bytes of transport-layer overhead + data:

• UDP: one datagram = $8+512=520$ B total, and only 8 B of that is overhead.
• TCP: handshake = 3 packets $\times$ 20 B $=60$ B, then the data segment $=20+512=532$ B. Total $=60+532=592$ B, with 80 B of overhead ($60$ handshake $+20$ header).
• UDP is leaner by $592-520=72$ bytes, and it also avoids the 1 round-trip delay of the handshake — which is why real DNS uses UDP first. Compare TCP.

L4.3 — We have 3 bytes: 0x12 0x34 0x56. Grouping into 16-bit words = 2 bytes each, the first pair is 0x12 0x34 = 0x1234. The third byte 0x56 is left without a partner (odd count), so we apply the padding rule: append a virtual zero byte 0x00, giving the second word 0x56 0x00 = 0x5600. This pad is not transmitted; it only completes the arithmetic. Now sum: $\text{0x1234}+\text{0x5600}=\text{0x6834}.$ No overflow, so no carry-wrap. One's-complement sum of the payload $=\text{0x6834}$. (Had we forgotten the pad, 0x56 alone as a low byte would give the same 0x5600 here — but with a nonzero high byte in the last word, dropping the pad would silently change the sum. Always pad to be safe.)

L5.1 — Choose UDP because timeliness beats completeness: a position update that arrives late is worse than useless — the object has already moved, so a retransmitted old packet just wastes bandwidth and stalls newer data (TCP's in-order guarantee causes head-of-line blocking: one lost packet freezes everything behind it). What you build yourself:

• Sequence numbers in your own payload, so you can discard stale updates and never act on an out-of-order old one.
• No retransmission of position — the next of 60/sec updates supersedes any lost one within ~16 ms.
• Selective reliability only for events that must land (e.g. "player fired", "player died"): re-send just those with your own ACK. Partial reliability is acceptable because most packets are self-correcting (superseded quickly); only rare state-changing events need guaranteed delivery.

L5.2 — QUIC builds on UDP for three reasons: (1) Deployability — UDP passes through existing routers, NATs, and firewalls that only understand IP + the two common transports; inventing a brand-new transport protocol number would be blocked everywhere. (2) Userspace evolution — TCP lives in the OS kernel and updates slowly; by treating UDP as a thin pipe, QUIC implements congestion control, reliability, and multiplexed streams in userspace, so it can iterate fast. (3) No head-of-line blocking across streams — TCP's single byte-stream stalls all data behind one lost segment; QUIC runs independent streams over UDP datagrams so a loss in one stream doesn't freeze the others. So UDP isn't chosen for its lack of features — it's chosen precisely because it's a minimal, transparent wrapper QUIC can build exactly the features it wants on top of.

UDP header size ::: 8 bytes, 4 fields of 16 bits each (Source Port, Dest Port, Length, Checksum). Why carry-wrap in the checksum ::: One's-complement addition recycles the overflow bit instead of discarding it, so no information is lost and the sum stays 16-bit. What $\overline{x}$ (bitwise complement) does ::: Flips every bit of the 16-bit number; e.g. $\overline{\text{0x0000}}=\text{0xFFFF}$. What to do with an odd-length payload before checksumming ::: Append one virtual zero byte (0x00) to make an even byte count; it is not transmitted and adds nothing to the sum. What 0x0000 in the checksum field means (IPv4) ::: "No checksum computed — skip verification." A genuine zero result is sent as 0xFFFF.