Question 2 of 7: Fundamental Concepts and Mechanisms

Question 2: Fundamental Concepts and Mechanisms (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) UDP vs. TCP by application/protocol. 1. File Transfer Protocol (FTP). TCP is used, on two separate connections (a control connection for commands and a data connection for the transfer itself): every byte of a transferred file must arrive complete, uncorrupted and in the original order, since a single dropped or reordered segment in an undetected UDP transfer would silently corrupt the file — TCP's reliability and ordering are exactly what bulk file transfer needs, and the connection-setup cost is amortized over the whole (usually large) transfer. 2. HTTP protocol. TCP is used: a Web page is a set of discrete resources (HTML, images, scripts) that must each arrive completely and correctly to render, and HTTP/1.1–2 further amortizes the one-time connection-setup cost by reusing a single TCP connection for many requests to the same server. 3. DNS protocol. Primarily UDP: a DNS query and its response normally fit in a single small packet, and the sheer volume of independent, latency-sensitive lookups a client or resolver performs makes UDP's low per-query overhead (no handshake) far more efficient than opening a fresh TCP connection per lookup — loss is handled simply, by the resolver retrying the query after a short timeout using the query's own transaction ID. DNS falls back to TCP only when a response would exceed a single UDP datagram's practical size (a large answer, e.g. many records or DNSSEC signatures) or for zone transfers between servers, where a single, ordered, reliable byte stream is what is actually needed. 4. YouTube (video streaming). Video delivery is built on top of TCP-based HTTP (progressive download or adaptive bit-rate streaming such as DASH/HLS, which fetch successive video-segment files over ordinary HTTP requests): reliable, in-order delivery is still required because a compressed video stream cannot tolerate an undetected dropped byte without visibly corrupting playback, and TCP's connection reliability lets the video simply be treated as any other Web resource, with a client-side playout buffer absorbing TCP's variable delivery latency. (Newer transports such as QUIC, built over UDP but providing its own reliability and stream multiplexing, are increasingly used underneath the same HTTP-based delivery model to reduce connection-setup latency and avoid head-of-line blocking across independent video segments, but the semantic requirement is still reliable, ordered delivery of every byte — UDP is never used unreliably for the compressed video payload itself.)

Given. Request 400 bytes, response 6000 bytes; per-packet latency 10 ms (applies identically local or remote, incurred once per packet); one-time TCP connection setup 6 ms; data transfer rate 10 Mbps; MTU 1500 bytes; server processing time 2 ms; network lightly loaded (no queuing delay).

Find. The total estimated elapsed time for (i) UDP, (ii) HTTP over TCP, and (iii) client and server on the same machine.

Approach. Model the time to move an L-byte message across the network as k packet-latencies (one per MTU-sized packet the message splits into) plus the message's own transmission time at the link's data rate, add the server's fixed processing time between request and response, and add the one-time TCP handshake only for the connection-oriented case.

1. Packet counts. The request (400 bytes) fits in one packet: $k_{req}=\lceil 400/1500\rceil=1$. The response (6000 bytes) needs $k_{resp}=\lceil 6000/1500\rceil=4$ packets.
2. Message transfer time. Define $T(L,k)=k\times10\ \text{ms}+\dfrac{8L}{10\times10^{6}}\times1000\ \text{ms}$. For the request: $$T_{req}=1(10)+\dfrac{8(400)}{10\times10^{6}}(1000)=10+0.32=10.32\ \text{ms}.$$ For the response: $$T_{resp}=4(10)+\dfrac{8(6000)}{10\times10^{6}}(1000)=40+4.8=44.8\ \text{ms}.$$
3. (i) UDP (connectionless). No connection to establish; the client sends the request, the server processes it, and sends the response directly. $$\boxed{T_{UDP}=T_{req}+T_{proc}+T_{resp}=10.32+2+44.8=57.12\ \text{ms}}$$
4. (ii) HTTP over TCP (connection-oriented). The same exchange is preceded by a one-time 6 ms handshake. $$\boxed{T_{TCP}=T_{setup}+T_{req}+T_{proc}+T_{resp}=6+10.32+2+44.8=63.12\ \text{ms}}$$
5. (iii) Same machine. The stated latency figure explicitly applies "local or remote," representing the fixed marshalling/context-switch overhead paid even between two processes on one host. With no physical network to cross, there is no MTU-driven fragmentation and the data-rate term becomes negligible. $$\boxed{T_{local}=10+2+10=22.0\ \text{ms}}$$