Question 2 of 7: Fundamental Concepts and Mechanisms

Question 2: Fundamental Concepts and Mechanisms

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.

Given. Request message 500 bytes, response message 5000 bytes; per-packet latency 5 ms (applies identically whether the two endpoints are local or remote, and is incurred once per packet transmitted); a one-time TCP connection-setup cost of 5 ms; a data transfer rate of 5 Mbps; an MTU of 1500 bytes (the maximum payload one packet can carry, so any message longer than this must be split into multiple packets); server request-processing time 3 ms; network lightly loaded (no queuing delay).

Find. The total estimated elapsed time from the client issuing the request to it receiving the complete response, for (i) UDP (connectionless), (ii) TCP (connection-oriented), and (iii) client and server co-located on one 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 is split 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 (500 bytes) fits in a single packet since it is under the 1500-byte MTU: $k_{req}=\lceil 500/1500\rceil=1$. The response (5000 bytes) needs $k_{resp}=\lceil 5000/1500\rceil=4$ packets.
2. Message transfer time. Define the time to move an L-byte message split into k packets as $$T(L,k)=k\times 5\ \text{ms} + \dfrac{8L}{5\times10^{6}}\times1000\ \text{ms}.$$ For the request: $$T_{req}=1(5)+\dfrac{8(500)}{5\times10^{6}}(1000)=5+0.8=5.8\ \text{ms}.$$ For the response: $$T_{resp}=4(5)+\dfrac{8(5000)}{5\times10^{6}}(1000)=20+8=28.0\ \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}=5.8+3+28.0=36.8\ \text{ms}}$$
4. (ii) TCP (connection-oriented). The same exchange is preceded by a one-time 5 ms handshake to establish the connection. $$\boxed{T_{TCP}=T_{setup}+T_{req}+T_{proc}+T_{resp}=5+5.8+3+28.0=41.8\ \text{ms}}$$ TCP is slower here purely because of the setup cost — its per-packet behaviour is otherwise modelled the same way, since at this level of estimation we ignore TCP's own acknowledgement traffic.
5. (iii) Same machine. The stated latency figure explicitly applies "local or remote," representing the fixed marshalling/context-switch/kernel-crossing overhead that is paid even for two processes on the same host, not just physical network propagation. With no physical network to cross, there is also no MTU-driven fragmentation of either message (both cross the local IPC channel as a single unit), and the data-rate term becomes negligible. $$\boxed{T_{local}=5+3+5=13.0\ \text{ms}}$$

(b) UDP vs. TCP by application. 1. Mail access protocols (POP3). TCP is used: a mailbox session involves an extended, stateful sequence of commands (login, list messages, retrieve specific messages) and every message must arrive complete and in order for the client to render it correctly — the reliability, ordering and flow control TCP provides are exactly what a multi-step, correctness-sensitive session needs, and the connection's setup cost is amortized over a long session. 2. Voice over IP. UDP is preferred: a voice call is a continuous, real-time stream of small audio samples where a late packet is worse than a lost one — a stalled TCP retransmission injects an audible gap that breaks the conversational round trip (interactive speech tolerates at most roughly 150 ms one-way delay), whereas dropping one UDP packet is a barely perceptible click concealed by the codec's error-concealment. VoIP therefore carries media over UDP (RTP), even though the call's own signalling/setup (SIP) typically runs over TCP where reliability matters more than latency. 3. Web browsing. TCP is used (as computed in part (a)): a Web page is a set of discrete resources (HTML, images, scripts) that must each arrive completely and correctly for the page to render, and modern HTTP/1.1–2 amortizes the connection-setup cost by reusing one TCP connection for many requests to the same server. 4. Global Positioning System (GPS). A GPS-based tracking application that periodically reports a device's position to a server typically uses UDP: each report is small, self-contained and quickly superseded by the next one, so a report lost in transit is not worth retransmitting (by the time a retransmission would arrive, the device has already moved and sent a newer, more relevant position anyway) — the application favours low latency and low per-report overhead over guaranteed delivery of every single stale position update.