optional · CSS study notes
Connectionless Transport with UDP (2017)
🧭
On this page — click any heading below to jump straight to it. ⬅️ Back to P-II.II. Computer Communications & Networks
OSI Layer: Transport Layer (L4)
Definition
UDP (User Datagram Protocol) is a connectionless, unreliable transport protocol (RFC 768) that adds only multiplexing and optional error checking to the best-effort service of IP.
Characteristics
- No handshake — sender transmits immediately, no setup delay
- No connection state — server supports more active clients
- No acknowledgement or retransmission — lost datagrams stay lost
- No ordering guarantee — datagrams may arrive out of sequence
- No built-in congestion control — the application or a protocol above UDP must limit its rate responsibly.
- Message-oriented — preserves message boundaries (unlike TCP's byte stream)
UDP Header (8 bytes, 4 fields of 2 bytes each)
- Source port — return address, optional (may be 0)
- Destination port — used for demultiplexing
- Length — header + data, in bytes
- Checksum — optional in IPv4, mandatory in IPv6
Checksum Working
- Sender treats segment as sequence of 16-bit words, computes 1's complement sum, then takes 1's complement of the result
- Receiver sums all 16-bit words including checksum; result should be all 1s (0xFFFF)
- Provides error detection only, no correction — corrupted datagram is silently discarded
Advantages
- Minimal overhead (8 vs 20 bytes) and low latency
- No connection setup delay — critical for one-shot queries like DNS
- Fine-grained application control over when and what is sent
- Supports broadcast and multicast (TCP cannot)
- Stateless servers scale better
Disadvantages
- Unreliable; application must implement its own recovery if needed
- No flow or congestion control — can cause network congestion collapse
- Plain UDP needs added reliability and congestion control for bulk transfer; protocols such as QUIC supply these.
Applications
- DNS — single request/response, retransmit at application level if no reply
- DHCP, TFTP, SNMP, RIP, NFS
- VoIP, video streaming, online gaming — timeliness beats perfect reliability
- QUIC — modern protocol running reliability and congestion control over UDP (used by HTTP/3)
UDP vs TCP
| Basis | UDP | TCP |
|---|---|---|
| Connection | Connectionless | Connection-oriented |
| Header | 8 bytes | 20 bytes minimum |
| Reliability | No built-in recovery | Reliable ordered stream when the connection succeeds; failures can still occur |
| Ordering | None | In-order |
| Congestion control | None | AIMD |
| Broadcast/multicast | Supported | Not supported |
| Example | DNS, VoIP | HTTP, FTP, SMTP |
Numericals
Q1 — Header efficiency
Payload = 40 bytes (typical VoIP sample).
- UDP: 40 ÷ 48 = 83.3%
- TCP: 40 ÷ 60 = 66.7%
- Saving = 12 bytes per packet; at 50 packets/sec = 600 B/s = 4.8 kbps saved per call
Q2 — VoIP bandwidth
Codec 64 kbps, 20 ms packets, headers = UDP 8 + IP 20 + Ethernet 26 = 54 bytes.
- Payload per packet = 64,000 × 0.02 ÷ 8 = 160 bytes
- Total frame = 160 + 54 = 214 bytes
- Packets/sec = 50 → 214 × 50 × 8 = 85,600 bps ≈ 85.6 kbps per call
- Overhead ratio = 54 ÷ 214 = 25.2%
Q3 — Checksum
Two 16-bit words: 0110011001100000 and 0101010101010101.
- Sum = 1011101110110101
- 1's complement (checksum) = 0100010001001010
- Receiver adds all three words → all 1s if no error
Q4 — Loss tolerance
Stream of 1,000 datagrams/sec, loss rate 1%.
- Lost = 10 datagrams/sec → for voice this is ~200 ms of dropped audio spread thinly, usually masked by concealment; for a file transfer it would corrupt the file, hence TCP
CSS Exam Angle
- Appeared in CSS 2017 — the examiner wants the justification, not just the definition: why choose an unreliable protocol deliberately
- Key argument: recovery must meet the playout deadline. A packet arriving after its deadline may be useless; timely retransmission can still help when the delay budget allows it.
- Mention QUIC/HTTP-3 as evidence UDP is not obsolete but foundational to modern web transport
- Always draw the 8-byte header diagram
Likely Questions
- Practice: explain UDP and justify its real-time use. The verified 2017 question asks about HTTP, SIP, TCP and UDP together; see the final section.
- Draw and explain the UDP header. How is the checksum computed?
- Compare UDP and TCP with application examples.
📜 Past-Paper Questions & Structured Answers
Questions are paraphrased; answer focus is suggested guidance, not an official marking scheme.
2017 · Paper-II · Q3(a) · 8 marks
Question (paraphrased): Explain HTTP and SIP, then TCP and UDP.
Answer focus: Eight marks cover all four protocols; give purpose, operation and one distinction for each.
| Protocol | Layer / purpose | Operation and example |
|---|---|---|
| HTTP | Application; web resource transfer | A client sends a request such as GET; a server returns a status and representation. It is request/response and stateless at protocol level. |
| SIP | Application; session signalling | REGISTER locates a user; INVITE/200 OK/ACK establishes a session and BYE ends it. SDP can describe media; RTP usually carries the audio/video separately. |
| TCP | Transport; reliable ordered stream | Establishes a connection, numbers bytes, acknowledges and retransmits losses; uses flow and congestion control. Suitable for file transfer. |
| UDP | Transport; lightweight datagrams | Sends separate messages using ports and a checksum, without its own connection setup or retransmission. Useful for delay-sensitive applications. |
Relationship: HTTP and SIP define application conversations; TCP/UDP provide transport. HTTP/1.1 and HTTP/2 use TCP; HTTP/3 uses QUIC over UDP. SIP can use UDP or TCP, with TLS commonly used over TCP. SIP signalling does not itself carry the voice stream.
2020 · Paper-I · Q3(c) · 4 marks
Question (paraphrased): Choose TCP or UDP for transferring a file and justify.
Answer focus: Name the protocol and explain reliability, ordering and the overhead trade-off.
Choose TCP for an ordinary complete file transfer. Every byte matters: TCP sequences the stream, detects corruption, acknowledges receipt and retransmits missing data. Ordered delivery makes the received file match the transmitted byte sequence, assuming the transfer completes successfully.
Connection setup and recovery add delay, but completeness matters more than avoiding a small wait. UDP alone would leave loss recovery and ordering to the application. An application can build reliable transfer above UDP, but plain UDP does not provide it.
2020 · Paper-I · Q3(d) · 4 marks
Question (paraphrased): Choose transport for live real-time audio and explain.
Answer focus: Latency priority, loss tolerance, UDP benefit and necessary application controls.
Choose UDP for a conventional interactive live-audio design. Audio samples have playout deadlines; retransmitting an old sample may make it arrive too late and delay subsequent playback if a reliable ordered stream is used.
UDP preserves datagram boundaries and supplies no retransmission delay of its own. RTP sequence numbers/timestamps, a short jitter buffer and loss concealment can help the receiver play timely audio. The application must still adapt its sending rate to congestion; UDP does not guarantee low latency or delivery. This argument is strongest for interactive calls, not all buffered video/audio services.
2021 · Paper-II · Q5(a) · 6 marks
Question (paraphrased): Compare TCP/UDP and explain their use over wireless networks.
Answer focus: Comparison plus wireless-specific behaviour, not just a generic table.
| Basis | TCP | UDP |
|---|---|---|
| Service | Connection-oriented byte stream | Connectionless messages/datagrams |
| Delivery | Sequencing, ACKs and retransmission support reliable ordered delivery | No built-in guarantee of arrival, order or duplicate suppression |
| Control | Receiver flow control and congestion control | Applications/protocols above UDP provide these if needed |
| Header / setup | At least 20 bytes; connection setup | 8 bytes; no UDP handshake |
| Suitable use | File transfer, remote login | Interactive media and short queries, with suitable application logic |
Wireless use: both operate over Wi-Fi or mobile IP links. TCP suits downloads and transactions requiring completeness, but loss-based TCP may treat wireless corruption or handover losses as congestion and reduce its rate unnecessarily. Link-layer retransmissions can help but also increase delay. UDP suits interactive media when timeliness is more important than recovering every packet; the application supplies congestion adaptation and any needed recovery. Neither transport is exclusively a wired or wireless protocol.
2026 · Paper-II · Q4 · 20 marks — related complete answer
The question compares TCP congestion handling with UDP and asks about network stability. Use the complete, developed answer in Congestion Avoidance; a short TCP/UDP table alone is insufficient for 20 marks.