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 400 bytes, response message 6000 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 10 Mbps; an MTU of 2000 bytes (the maximum payload one packet can carry, so any message longer than this must be split into multiple packets); server request-processing time 2 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, (ii) TCP, 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 (400 bytes) fits in a single packet since it is under the 2000-byte MTU: $k_{req}=\lceil 400/2000\rceil=1$. The response (6000 bytes) needs $k_{resp}=\lceil 6000/2000\rceil=3$ 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}{10\times10^{6}}\times1000\ \text{ms}.$$ For the request: $$T_{req}=1(5)+\dfrac{8(400)}{10^{7}}(1000)=5+0.32=5.32\ \text{ms}.$$ For the response: $$T_{resp}=3(5)+\dfrac{8(6000)}{10^{7}}(1000)=15+4.8=19.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}=5.32+2+19.8=27.12\ \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.32+2+19.8=32.12\ \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+2+5=12\ \text{ms}}$$

(b) UDP vs. TCP by application. 1. Mail access protocols (IMAP). TCP is used: a mailbox session involves an extended, stateful sequence of commands (login, list folders, fetch 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. Internet radio. UDP is preferred: the stream is a continuous sequence of audio samples where a late packet is worse than a lost one (a stalled TCP retransmission causes an audible gap, whereas dropping one UDP packet is a barely perceptible glitch), so the application favours low, steady latency over guaranteed delivery and tolerates loss with error concealment. 3. Information browsing (HTTP). 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. Remote procedure call. Either can be used depending on the semantics wanted: TCP-based RPC gives at-most-once/exactly-once-like guarantees for large or multi-part calls where retry logic would be complex to hand-roll, while UDP-based RPC (with the request-reply protocol adding its own lightweight retransmission-on-timeout and duplicate filtering) is common for small, idempotent, latency-sensitive calls (e.g. within a data-center) because it avoids the connection-setup overhead on every call.