TCP Flow Control: The Receive Window

Every TCP ACK includes a window field advertising how many bytes the receiver is willing to accept. This prevents a fast sender from overwhelming a slow receiver.

Sender                                    Receiver
   |  ---- data (1000 bytes) ---->            |
   |  <---- ACK, window=64000 ----            |  "I can accept 64KB more"
   |  ---- data (1000 bytes) ---->            |
   |  <---- ACK, window=63000 ----            |  "Now 63KB" (read 0 bytes)
   |  ---- data (1000 bytes) ---->            |
   |  <---- ACK, window=65000 ----            |  "65KB" (app read 3KB)

The sender can have up to window bytes of unacknowledged data in flight. If the window shrinks to zero, the sender must stop and wait.

Window scaling: The 16-bit window field limits the window to 64KB, which is too small for high-bandwidth or high-latency links. TCP window scaling (negotiated in the SYN handshake) multiplies the field by 2^scale. Modern systems use scale factors of 7-8 (128-256×), allowing windows of 8-16MB.

Congestion Control: CWND and Slow Start

Besides the receive window (rwnd), TCP maintains a congestion window (cwnd) limiting how much data can be in flight based on estimated network capacity. The actual limit is min(rwnd, cwnd).

Time →

cwnd: [1] [2] [4] [8] [16] [32] [64] ... [128] ↓ [64] [65] [66] ...
       |                                        |
       Slow Start (exponential)                 Loss detected!
                                                 ↓ cwnd halved, then
                                                 Congestion Avoidance (linear)

Slow Start: cwnd starts small (1-10 segments) and doubles every RTT until loss or threshold.
Congestion Avoidance: After loss, cwnd increases by ~1 segment per RTT (additive increase).
On loss: cwnd is halved (multiplicative decrease). This creates the sawtooth pattern.

Recovery from loss is slow because TCP must re-probe for capacity. A single loss event can take seconds to recover, during which throughput is degraded.

Retransmission: Fast Retransmit vs RTO

TCP has two mechanisms to detect and recover from loss:

• Fast Retransmit: 3 duplicate ACKs trigger immediate retransmit (doesn't wait for timeout). Works when subsequent packets arrive, generating dup ACKs.
• RTO (Retransmission Timeout): If no ACKs arrive, TCP waits for a timeout (often 200ms-1s minimum), then retransmits. Timeout doubles on each retry.

Tail loss is particularly problematic: if the last packets of a burst are lost, there are no subsequent packets to trigger dup ACKs, so TCP must wait for RTO. This causes multi-second stalls for what might be a single lost packet.

Nagle's Algorithm

Nagle's algorithm (RFC 896) prevents sending small packets when previous data is unacknowledged:

if (unacked_data > 0 && new_data < MSS):
    buffer new_data until ACK received
else:
    send immediately

This is efficient for bulk transfers but terrible for interactive protocols. Combined with delayed ACK (receiver waits 40-200ms before sending ACK), it creates artificial latency.

Solution: Set TCP_NODELAY socket option to disable Nagle's algorithm.

ECN (Explicit Congestion Notification)

ECN allows routers to signal congestion without dropping packets:

1. Router marks packet with CE (Congestion Experienced) in IP header
2. Receiver sets ECE (ECN-Echo) flag in TCP ACK
3. Sender reduces cwnd and sets CWR (Congestion Window Reduced)

ECN provides earlier congestion signals than loss, allowing TCP to react before queues overflow. JitterTrap shows ECE and CWR markers on the TCP Window chart.

RTT Measurement

JitterTrap measures RTT by tracking TCP sequence numbers and their acknowledgements:

RTT = time(ACK received) - time(segment sent)

For segment with sequence S:
  - Record send_time when packet with seq=S observed
  - Record ack_time when ACK covering S observed
  - RTT sample = ack_time - send_time

This passive measurement doesn't require modifying endpoints. Accuracy depends on seeing both directions of the flow. Retransmitted segments are excluded (ambiguous which transmission was ACKed).

RTP (Real-time Transport Protocol)

RTP is the standard protocol for streaming media over IP networks. Each RTP packet contains:

• Sequence number (16-bit) — detects packet loss and reordering
• Timestamp (32-bit) — synchronizes playback timing
• SSRC (32-bit) — identifies the stream source
• Payload type (7-bit) — indicates codec (though often dynamically assigned)
• Marker bit — typically indicates end of a video frame

RTP usually runs over UDP on even-numbered ports (e.g., 5004), with RTCP control messages on the next odd port (e.g., 5005).

RTSP (Real Time Streaming Protocol)

RTSP is a signaling protocol (like SIP for VoIP) that sets up RTP streams. An RTSP session typically:

1. DESCRIBE — client requests stream information
2. Server sends SDP — describes available media (codec, resolution, ports)
3. SETUP — client requests specific tracks
4. PLAY — server starts sending RTP packets

JitterTrap passively observes RTSP signaling to learn codec information from SDP, which is more reliable than guessing from packet inspection.

H.264/H.265 NAL Units

A NAL (Network Abstraction Layer) unit is the basic packaging unit for H.264/H.265 video data. Think of it as an envelope that wraps different types of video information.

Video codecs need to send different types of data: configuration info, keyframes, and delta frames. NAL units provide a standard way to identify what type of data is inside, delimit where one chunk ends and another begins, and transport video over networks.

NAL unit structure:

+----------------+---------------------------+
| NAL Header     | NAL Payload               |
| (1-2 bytes)    | (variable length)         |
+----------------+---------------------------+

Common NAL types (H.264):

Why this matters for JitterTrap:

• SPS parsing — JitterTrap reads the SPS to extract resolution, profile, and level. Without an SPS, we can't know the video dimensions.
• IDR detection — Playback can only start at an IDR (keyframe) because non-IDR frames reference previous frames we didn't capture. That's why you see "Waiting for keyframe".
• GOP calculation — By counting frames between IDRs, we measure the Group of Pictures size.

What arrives in a typical stream:

Time →

[SPS][PPS][IDR][P][P][P][P][P][P][P]...[IDR][P][P]...
 ↑    ↑    ↑                            ↑
 |    |    |                            Next keyframe (GOP boundary)
 |    |    Keyframe - playback can start here
 |    Encoding parameters
 Resolution, profile, level

IP cameras typically send SPS+PPS before each IDR, so you get fresh configuration with every keyframe. This is why resolution/profile often shows "-" until the first keyframe arrives.

SSRC and Stream Multiplexing

A single UDP flow (IP:port pair) can carry multiple RTP streams, each with a different SSRC. Common scenarios:

• Audio + Video — same ports, different SSRCs
• Simulcast — multiple quality levels, each with its own SSRC
• SSRC collision — rare, but SSRCs can change mid-stream if detected

JitterTrap tracks each SSRC separately, so audio and video from the same source appear as distinct entries even if they share an IP/port.

Jitter Calculation

For each packet, JitterTrap computes:

D = (arrival_time - prev_arrival) - (rtp_timestamp - prev_timestamp) / clock_rate

This measures the difference between actual and expected inter-packet time. The displayed jitter is the mean |D| over the last second. Unlike RFC 3550's smoothed jitter (which has an 1/16 smoothing factor), this shows actual recent variance and responds quickly to network changes.