CSS Prepare

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

BasisUDPTCP
ConnectionConnectionlessConnection-oriented
Header8 bytes20 bytes minimum
ReliabilityNo built-in recoveryReliable ordered stream when the connection succeeds; failures can still occur
OrderingNoneIn-order
Congestion controlNoneAIMD
Broadcast/multicastSupportedNot supported
ExampleDNS, VoIPHTTP, 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

  1. 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.
  2. Draw and explain the UDP header. How is the checksum computed?
  3. 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.

ProtocolLayer / purposeOperation and example
HTTPApplication; web resource transferA client sends a request such as GET; a server returns a status and representation. It is request/response and stateless at protocol level.
SIPApplication; session signallingREGISTER 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.
TCPTransport; reliable ordered streamEstablishes a connection, numbers bytes, acknowledges and retransmits losses; uses flow and congestion control. Suitable for file transfer.
UDPTransport; lightweight datagramsSends 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.

BasisTCPUDP
ServiceConnection-oriented byte streamConnectionless messages/datagrams
DeliverySequencing, ACKs and retransmission support reliable ordered deliveryNo built-in guarantee of arrival, order or duplicate suppression
ControlReceiver flow control and congestion controlApplications/protocols above UDP provide these if needed
Header / setupAt least 20 bytes; connection setup8 bytes; no UDP handshake
Suitable useFile transfer, remote loginInteractive 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.

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.