1.1.f (i) Starvation
This section discusses TCP Starvation, UDP dominance.
As you now know, TCP is connection oriented, and is able to detect network congestion and act accordingly (slow start following by back off with packetloss).
UDP has no concept of this congestion window, all UDP will do is continue to send whatever the upper layer protocols send down to it. If there is congestion, UDP
does not care, if there is packet loss, UDP does not care. UDP is oblivious to its surroundings.
When mixing these two protocols into the same output pipe (aka internet connection) we need to be aware of their limitations.
TCP starvation refers the notion of a big stupid UDP stream eating up all of the banwidth and not sharing at all.
During periods of congestion our TCP stream will back off and start from its slow start threshold again, while the UDP stream will realize there is more bandwidth
and start to transmit even more.
Notice the above graph, TCP notices packet loss when the UDP flow ramps up and then TCP backs off.
The UDP flow realizes more banwidth because it never backs up. Thus the TCP flow continues to suffer.
This behavior is TCP starvation, UDP dominance. The recipe is in the name.
What 4 solutions do we have for this?
1. Enact a fair queuing mechanism on the output queue
2. limit the UDP connection from the application layer
3. Put UDP and TCP in different queues
4. Get a separate connection for the UDP traffic.
1.1.f (i) Starvation