CND (312-38) Network Defense Simulation
Network Scenario
An enterprise network is experiencing variable latency on a WAN link used for real-time video streaming (unicast). The network administrator needs to ensure that the streaming application does not consume all available bandwidth, which would starve critical database synchronization tasks relying on standard TCP. The goal is to implement a mechanism that allows the stream to be "TCP-friendly," meaning it adjusts its rate based on network congestion similarly to how TCP does, but without the abrupt window size changes that would degrade video quality.
Traffic & Logs
[TIMESTAMP: 2023-10-24 14:22:01]
[SOURCE: 10.0.45.10 (Media Server)]
[DESTINATION: 192.168.100.55 (Remote Branch)]
[PROTOCOL: UDP / TFRC-Mechanism]
[STATUS: Adjusting packet rate based on RTT and Loss Rate]
[OBSERVATION: Flow is maintaining fairness with concurrent TCP sessions on port 443]
---
[NETFLOW DATA]
- App_ID: Video_Stream_01 | Bitrate: 4500kbps | Packet_Loss: 0.2%
- App_ID: DB_Sync_01 | Bitrate: 1200kbps | Protocol: TCP (Cubic)
Question
Which of the following is a congestion control mechanism that is designed for unicast flows operating in an Internet environment and competing with TCP traffic?
Think about a mechanism specifically designed to allow non-TCP applications (like streaming) to behave "fairly" alongside standard TCP flows without causing starvation.
Expert Analysis
1. Network Analysis: The logs show a media server transmitting data to a remote branch. The network is detecting congestion, and the protocol in use is intentionally adjusting its rate to remain "fair" to other TCP sessions (like the DB sync).
2. Behavior Identification: This behavior is known as "TCP friendliness." Standard TCP uses AIMD, which results in "sawtooth" throughput. For streaming, this sawtooth pattern causes jitter. The mechanism used here provides a smoother rate while still backing off when congestion is detected.
3. Why Correct Answer is Correct: TCP Friendly Rate Control (TFRC) is specifically defined (RFC 5348) for unicast flows. It uses a throughput equation based on loss rate and RTT to ensure it doesn't take more than its fair share of bandwidth compared to a standard TCP flow under the same conditions.
4. Why Others are Wrong:
- Sliding Window: This is a flow control mechanism used to ensure the sender doesn't overwhelm the receiver's buffer; it is not specifically a competitive congestion control mechanism for Internet environments.
- Selective Acknowledgment (SACK): This is a TCP feature that allows a receiver to inform the sender about all segments that have been received successfully, so only missing segments are retransmitted.
- AIMD: While TCP uses Additive Increase/Multiplicative Decrease, it is the *underlying algorithm* of TCP, not a separate mechanism designed *for* other flows to compete with TCP.
5. Defensive Action: As a Network Defender, you should monitor non-TCP traffic (UDP) to ensure it implements TFRC or similar mechanisms. Traffic that does not back off during congestion (greedy flows) should be rate-limited or prioritized via QoS (Quality of Service) to prevent Denial of Service (DoS) conditions on critical TCP business traffic.
- Traffic Pattern: TCP (AIMD) has a sharp drop in rate when a packet is lost. TFRC has a much smoother rate change.
- Protocol Behavior: Uncontrolled UDP traffic is "greedy." TFRC makes UDP "polite."
- Detection: Defenders use NetFlow to compare throughput vs. loss rate. If throughput stays high despite high loss, the flow is likely not congestion-controlled.
Explore more CND simulations:
https://exam.practice-tests.org