Exercise 2: TCP vs. UDP for a Live Video Call Stream — Possible Solution
====================================================================

Recommendation: UDP.

Why TCP's own guarantees would actually hurt here:

Per the chapter, TCP guarantees delivery specifically through
retransmission: "if an expected acknowledgment doesn't arrive in time,
TCP retransmits." For a live video call, this is a real liability, not
a benefit. If a video frame is lost in transit, TCP's own mechanism
would hold up delivery of every subsequent frame until the lost one is
successfully retransmitted and its correct order is restored -- per
the chapter, TCP guarantees data "arrives in the correct order," which
necessarily means later data waits behind earlier data that hasn't
arrived yet. For a LIVE call, that lost frame is already stale by the
time it could be retransmitted and delivered -- the call has moved on
to what's happening now, not what happened a moment ago. Waiting for
it, and blocking newer frames behind it, would show up to the user as
a stutter or freeze, when the useful thing to do instead is simply
skip the lost frame and keep displaying whatever comes next.

Why UDP fits: per the chapter, "a late frame is often worse than a
missing one -- better to skip it than stall waiting for a
retransmission" -- this is precisely the video/voice call scenario the
chapter names directly as UDP's own typical use case. UDP sends each
frame's data with no built-in delivery guarantee and no built-in
ordering guarantee, which means a lost frame is simply lost -- the
call continues immediately with the next frame that does arrive,
without any protocol-level mechanism forcing a pause to wait for
what's missing.

The deeper reason this is the right tradeoff: for a live call, the
value of any single frame decays extremely fast -- a frame from half a
second ago is close to worthless once the conversation has moved on.
TCP's own reliability guarantees are built around the opposite
assumption (that every single byte matters and must arrive correctly,
however long that takes), which is exactly backwards for this
particular kind of real-time data.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains specifically HOW TCP's own reliability mechanism (in-
order delivery via retransmission) would actively degrade a live video
call (stale frames blocking newer ones) rather than just stating "UDP
is for real-time," and ties the recommendation directly to the
chapter's own stated reasoning for that use case.