1
Introduction
We are here to address two issues: 1. “packet loss somehow creates an allocation of bandwidth between multiple users of the same network pipe’ and 2. “how a conflict might arise between traffic using streams and traffic using datagrams”. Before going on to address such issues, we will first tell a story about TCP’s amazing flow and congestion control. Actually, the story will give us a good insight for our further analysis of those issues.
1.1 An Amazing Control by TCP
You just cannot send someone something before he is ready to receive. As a TCP sender, you cannot overwhelm the receiver with data more than the size of his permissible window. Now from the sender’s point of view he would have really appreciated in a good network condition (without congestion) if receiver would accept whatever amount he sends. But TCP has better and simple ways of thinking about this world. This is what it has to say, “TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.” [rfc793: robustness] Therefore, sender needs to be content with whatever window size receiver wishes to accept and all his life, he will send an acceptable amount of data at a time. This is what we call flow control.
Now suppose, we have bottleneck in our hand and more worse, everybody is trying to send everything through this bottle necked link. The Router, which stands at the beginning point of this bottleneck, is throwing out packets because of the its processing capacity. Each TCP sender is thinking he will soon receive the ACKs for his packets. But how can the receiver send one such ACK without getting the expected SEQ of data. So there is no ACK coming to the sender for sure. Senders’ timer will expire eventually, and they will say to themselves how about sending those packets once more. With everybody sending once again, the link goes bizarre. Now whatever you do you cannot get rid of those packets from the queue until you get the ACKs. You are in a trouble, you thought you could just send as much packets as you wanted; no surely, you cannot this time, because of all those outstanding packets your own buffer is on the verge of exploding (of course you can discard those packets by dreaming that have reached. Then you will not be a reliable sender, will you?). Hence, as a sender, you need to control your sending capability and you need to be patient and wait for opportune moment. TCP calls it congestion control. You need to be patient now. You are now a reasonable packet sender. This helps you and above all, you can be polite and help other senders too. There is no point fighting with people who wants the same passage (link). Moreover, for each one of you contenders, this is a lose-lose (loss-loss) situation. At this point TCP senders do congestion control.
You cannot overwhelm receiver window (if the receiver does
not accept what good is by sending) and you cannot send more than congestion
window (the size of buffer which makes sense for a congested network) either.
So, congestion window <= receiver window. If all the links from the sender
to the receiver were capable of taking any amount then congestion window =
receiver window. In that case, there is no need for a congestion window either
and in fact, it is more appropriate to call it sender window.
|
|
Figure 1 Showing Network congestion by the bottleneck
2 Packet Loss and Available Bandwidth
Packet loss arises due to transmission error in the link or by drop of packets in the router. Now days, the former case of packet loss is rare (for wireless it is an important issue). We can say that congestion or packet loss is caused by the latter case. For protocols such as TCP or DCCP that care about congestion, loss of packets will trigger congestion control.
Let us suppose S1, S2, S3, S4, S5 are trying to send packets
to any of D1, D2, D3, D4 and D5. The large ellipse is the network. A and B are
two routers. The link between A and B is shared by each of the source. Now the
total packets send at a given time cannot be larger than the link size. Let X =
the number of bytes processable by A, the link and B for a time interval t. We
can think of the circle in the figure as virtual bottleneck node with queue
length X. We can safely say that for time interval t, the total packet size by
senders 
(where
N is the number of packets and L is the total packets send in t
interval by a sender) cannot be greater than X.
Suppose at least one sender is using TCP as its transport protocol. TCP has congestion control, so it will increases its congestion window every time an ACK comes and halves its window for a congestion signal.
With the congestion signal, at least one of the senders (that uses TCP) will lower its congestion window and the total length bytes will be less than X. This creates an available space for other senders (even a new sender can send along this path). However, if none of the transport protocol of the senders use congestion control, there will not be any increase of available bandwidth. In any case, such protocols do not care about reliability; they only care about the timeliness of packet-arrival.
3
Conflict between
Streams and Datagrams
We call a packet a datagram, when it uses an unreliable service [wiki:Packet]. Unreliable service means there is no acknowledgment of a packet’s reception. UDP is an unreliable transport service over IP. We call UDP packet a datagram. Whereas, TCP provides a reliable end-to-end byte stream transfer. TCP accepts streams from local applications and provides in-order reliable packet delivery to the receiver to create the original stream. And TCP and UDP form the bulk of packets in the network. So our topic is to figure out the conflict between TCP and UDP.
This conflict arises due to congestion in the network but this issue has two dimension. There is no win for TCP or UDP alone. One of them has to suffer for the other. We discuss this in the following sections.
3.1 TCP’s Problem because of UDP:
Bandwidth
Section 1 details the congestion scenario and Section 2 relates what happens when packets are dropped. In the figure, let us say S1 uses TCP and all the others use UDP. In case of congestion, S1’s transmission rate or bandwidth will decrease. It actually follows from the following equation [The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm by M. Mathis et. el].
With the increase of the probability of packet loss, S1’s bandwidth decreases. On the other hand, UDP has little to care about this congestion. There is no way it will delay its shipment. UDP packets from other senders will keep the bottleneck queue almost full. TCP’s congestion window will not be able to grow a lot. Congestion trigger will cause even more reduction of congestion window.
Now here is how the worst scenario occurs; all the UDP sources are making sure that they will keep the bottleneck queue full all the time and whenever a TCP packet comes it is dropped. TCP will now have to wait forever to transmit a packet.
3.2 UDP’s Problem because of TCP:
Packet Loss
In the previous section, we thought that TCP is the one who is losing all the time. It is because we never considered the fact that UDP is actually losing packets because of congestion.
The worst-case scenario depicted earlier is not a possibility in the real world. UDP has no feedback method. So UDP does not know that it is gaining available places in the bottleneck queue and that the packets are not dropped. If UDP knew, it could have increased its packet size and also the rate of delivery. On the contrary, UDP will maintain its rate of packet transfer. Another point to note that, there is an average delay of arrival of packet in the queue. Hence, during the delay if a TCP packet arrives and fills the queue, an UDP packet coming after that will be dropped.
Again, 80% of the internet traffic uses TCP. Therefore, UDP datagram are dropped most of the time. [Characteristics of UDP Packet Loss: Effect of TCP Traffic] by H. Sawashima et.al actually elaborates this issue of UDP’s packet loss because of TCP elaborately evaluation for different scenario.
4 Conclusion
I want to say, I love TCP, although UDP and TCP has different purpose. Actually, there will come change for UDP like unreliable protocols (like the emergence of DCCP) but TCP is here to stay (SCTP is knocking but without any good response.)