UDP is often reduced to "fast but unreliable", while congestion control, RTT timers and silly window syndrome become separate lists to memorise. That leaves students mixing up receiver protection, network protection and application responsibilities. UDP's actual service is distinct from controls used by TCP and congestion-responsive applications. UDP header fields, checksum arithmetic, congestion traces and socket calls show how these transport-layer concepts work.
UDP and congestion control: build the transport-layer map first
The transport layer uses port numbers for process-to-process delivery. At the sender, multiplexing accepts data from applications. At the receiver, demultiplexing routes each unit to the right application. UDP, reliability, flow control and congestion control have distinct roles.
Idea | What it does | What it protects or supplies |
|---|---|---|
UDP | Sends connectionless datagrams | Message boundaries with little protocol state |
Reliability | Handles loss, duplication and ordering | Delivery guarantees the application requires |
Flow control | Limits sending to receiver capacity | The receiving endpoint |
Congestion control | Adjusts load to path capacity | Routers, links and queues on the network path |
"UDP is always faster" is too vague. Compare the guarantees and control state UDP and TCP provide, not raw speed. UDP checksum arithmetic and network-load control answer different questions from a full TCP reliability trace.
UDP header and checksum: a complete worked datagram
The four 16-bit UDP fields are source port, destination port, length and checksum. With source port 40000 (0x9C40), destination port 53 (0x0035) and payload 61 62 63 64 ("abcd"), length is:
8-byte header + 4-byte payload = 12 bytes = 0x000C
For the IPv4 checksum, the pseudo-header words are source IP 192.0.2.1 as 0xC000, 0x0201, destination IP 198.51.100.2 as 0xC633, 0x6402, protocol as 0x0011, and length 0x000C. UDP contributes 0x9C40, 0x0035, 0x000C, 0x0000; data contributes 0x6162, 0x6364.
Adding all 16-bit words gives raw sum 0x34D9A. Fold the carry back using one's-complement addition:
0x4D9A + 0x0003 = 0x4D9D
Complement every bit:
~0x4D9D = 0xB262
Verification gives 0x4D9D + 0xB262 = 0xFFFF. The pseudo-header detects wrong IP endpoints or protocol but is not transmitted in the UDP header. IPv4 permits a zero UDP checksum; standard UDP over IPv6 requires one.
Network congestion: recognise overload before choosing a control
Congestion is sustained offered load beyond bottleneck and queue capacity. A 10 Mb/s link receiving three 4 Mb/s flows gets 3 x 4 = 12 Mb/s, so its queue grows at 12 - 10 = 2 Mb/s = 0.25 MB/s. A decimal 1 MB queue fills in 1 / 0.25 = 4 seconds, assuming constant rates and no overhead.
The sequence is rising queueing delay, a full buffer, drops, then perhaps more load from blind retransmission. Flow control differs: a 6 Mb/s sender can overflow a 3 Mb/s receiver on an empty 10 Mb/s path. The receiver, not the link, is limiting.
Open-loop control acts before congestion appears and before any feedback arrives. It prevents overload through admission control and by choosing retransmission, window, acknowledgement and discard policies in advance. Closed-loop control reacts after congestion appears, using loss, rising delay, explicit signals, choke messages or backpressure.
If three bursty 4 Mb/s flows briefly offer 12 Mb/s to a bottleneck that drains at 10 Mb/s, a leaky bucket smooths the burst into a strict steady output rate so it does not slam the queue. A token bucket instead tolerates a controlled burst, allowing a flow to exceed its average rate briefly using a saved allowance, then making it fall back.
Congestion window evolution: slow start and AIMD step by step
For this textbook rule, start at cwnd = 1 MSS, ssthresh = 8 MSS; double once per RTT below the threshold, then add 1 MSS per RTT. Halve on congestion indication and reset to 1 MSS on timeout.
Start-of-RTT values are 1, 2, 4, 8, 9, 10 MSS. Congestion at 10 sets ssthresh = cwnd = 5 MSS; avoidance gives 6, 7 MSS. Timeout at 7 sets ssthresh = floor(7/2) = 3 MSS, cwnd = 1 MSS.
With MSS = 1000 bytes, cwnd = 10 MSS and RTT = 100 ms = 0.1 s, 10 x 1000 = 10,000 bytes may be in flight. Ideal window-limited rate is 10,000 / 0.1 = 100,000 bytes/s = 0.8 Mb/s, before headers. The usable window is commonly min(cwnd, rwnd).
Reno, Tahoe and other variants handle duplicate acknowledgements and fast recovery differently. Follow the question's exact rule. For a deeper TCP-only comparison, TCP Congestion Control for GATE: cwnd Table and Loss Rules follows slow start, timeout and triple-duplicate-ACK behaviour. TCP variants decide how cwnd reacts to loss; UDP itself supplies no congestion window.
RTT timers and silly window syndrome: related TCP controls, not UDP fields
Take old SRTT = 100 ms, old RTTVAR = 20 ms, new sample R = 140 ms, alpha = 1/8, beta = 1/4 and K = 4. Use the old SRTT in the deviation:
RTTVAR_new = (3/4)(20) + (1/4)|100 - 140| = 15 + 10 = 25 msSRTT_new = (7/8)(100) + (1/8)(140) = 87.5 + 17.5 = 105 msRTO = 105 + 4(25) = 205 ms
Karn's rule avoids ambiguous post-retransmission RTT samples. Exponential backoff increases RTO after timeout.
Silly window syndrome arises when a receiver advertises tiny freed spaces or a sender makes tiny writes. Clark delays small receiver-side window updates. Nagle coalesces small sender-side writes while data is unacknowledged.
Timers, advertised windows and SWS fixes belong to TCP byte-stream behaviour. A UDP application may build timer and rate logic, but UDP does not supply them.
UDP socket programming: trace one datagram through the API
A server calls socket(AF_INET, SOCK_DGRAM, 0), bind() on 127.0.0.1:9000, recvfrom(), then sendto() with the returned client address. A client calls socket(), sendto() from ephemeral port 49152 to 9000, then recvfrom(). UDP needs neither listen() nor accept() and has no transport handshake.
A 32-byte message plus UDP's 8-byte header makes length 40; the IP header is outside it. One recvfrom() gets one datagram, subject to buffer truncation, not an arbitrary stream slice. UDP connect() may set a default peer but creates no TCP-style handshake.
Checksum detects corruption but cannot recover data. An application protocol seeking ordered, duplicate-suppressed delivery must add sequence numbers, acknowledgements, retransmission timers and duplicate detection for loss, duplication and reordering.
UDP and congestion control questions: exam patterns and traps
IIT Guwahati's official GATE 2026 CS syllabus lists transport-layer flow control and congestion control, UDP, TCP and sockets in Section 10. Relevant question skills include header-length arithmetic, one's-complement checksum, socket-call ordering, flow-control versus congestion-control classification, cwnd traces, RTT/RTO calculation and matching SWS fixes.
Common traps have direct corrections:
Treating UDP length as payload length gives a value eight bytes too small. Include the header.
Treating the pseudo-header as transmitted invents bytes on the wire. It is checksum input only.
Saying UDP prevents congestion confuses missing control with protection. The application must respond safely.
Confusing
cwndwithrwndmisses whether the path or receiver is limiting the sender. Check both.Applying a Reno response to another stated rule changes the trace. Use the question's rule.
Updating RTT variation from the new SRTT changes the baseline. Use the old SRTT for the shown formula.
Assigning Nagle and Clark to the wrong endpoints reverses their jobs. Nagle is sender-side; Clark is receiver-side.
Test the distinctions with TCP and UDP MCQs: 12 Solved Transport Layer Questions; that set trains question recognition, while recomputing the checksum, cwnd and RTT values trains the calculations.
UDP and congestion control: the short version and next step
UDP preserves datagram boundaries.
UDP length includes its 8-byte header.
Its checksum covers a pseudo-header that is not part of the transmitted UDP header.
Flow control protects the receiver.
Congestion control protects the network path.
TCP timers and silly window syndrome logic are not UDP header services.
Keep four numerical anchors: the worked datagram is 12 bytes, its checksum is 0xB262, bottleneck overload is 2 Mb/s, and the worked RTO is 205 ms.
Use GATE CS Exam Preparation as the broader subject route. GATE Guidance by Sanchit Sir is the structured path if you want the transport layer sequenced with the rest of Computer Networks. If you only need this topic, first recompute 0xB262, redraw the cwnd trace and write the UDP client-server call order from memory.
