# Exercise 2: Choosing a Protocol for a Mobile App on a Lossy Network

## Scenario

You're building the networking layer for a mobile app used by field technicians who work in areas with spotty cellular coverage — connections regularly drop 1-3% of packets, and users frequently move between WiFi and cellular (which changes the device's IP address mid-session). The backend team can support HTTP/1.1, HTTP/2, and HTTP/3, and asks you to pick a default.

Two options are on the table:
- **Option A**: HTTP/2 over TCP+TLS (widely supported, mature tooling).
- **Option B**: HTTP/3 over QUIC (newer, requires UDP to be permitted by the network).

## Deliverables

1. **Explain the packet-loss problem for Option A precisely.** The app makes several concurrent API calls per screen (multiplexed over one HTTP/2 connection). Using the real distinction between HTTP-level and transport-level head-of-line blocking from the theory file, explain exactly what happens to *all* of those concurrent calls when a single packet is lost on a 2%-loss cellular link — and why HTTP/2's stream multiplexing does not protect against this specific failure mode.

2. **Explain why Option B behaves differently under the same packet loss**, referring to QUIC's per-stream loss recovery specifically (not just "QUIC is newer/better").

3. **Explain the connection-migration angle.** A technician's device switches from WiFi to cellular mid-request, changing its IP address. Research (or reason from what you know of QUIC's connection IDs vs TCP's connection identification by IP+port tuple) why this matters for whether the in-flight request needs to restart from scratch. State which option handles this better and why, in terms of what identifies a "connection" in each protocol.

4. **Give your recommendation with one caveat.** State which option you'd default to, and name one real deployment risk of that choice (e.g., something about UDP and networks that field technicians might be connected to, such as restrictive corporate or government WiFi) along with what fallback behavior your app should implement to handle that risk.