[SOLVED] When packet drop occurs in a link with VoIP and TCP working concurrently?

When packet drop occurs in a link with VoIP and TCP working concurrently?

Let's assume TCP Reno version

I have this situation: a VoIP (UDP) stream and a TCP session on the same host. Let's say at t=10s the TCP opens the session with the TCP receiver (another host), they exchanges the max window during the 3-way handshake and then they start the stream with the slow start approach.

At t=25s, a VoIP stream starts. Since it's an UDP stream, the aim is to saturate the receiver. Not having any congestion control, it should be bursting packets as much as it can.

Since there is this concurrency in the same channel and we are assuming that in the topology of the network no router goes down etc (so no anomalies), my question is: Is there any way for achieve packet loss for the VoIP stream?

I was thinking that since VoIP is sensible to jitter, and the slow-start approach of TCP is not really slow, the packet loss could be achieved because the routers queues add variation of delay and they are "flooded" by the TCP early packets.

Is there any other reason?

Solution

A couple of comments first:

VoIP will not usually 'saturate' the receiver (or the network) - it will simply send as many packets as it needs for the particular codec you are using. In other words it won't just keep growing until it fills the network.
VoIP systems are sensitive to jitter as you note. Packet loss is actually related to this as a VoIP system will generally consider a packet lost if it arrives outside the jitter buffer window. So even though the packet may not in fact be lost, and only delayed, if it arrives outside the jitter buffer window it is effectively lost as far as the VoIP system is concerned.

Answering your specific question: yes other traffic can create delayed packets which may appear lost to the VoIP receiver. It is worth nothing that in a link where UDP and TCP are sharing the bandwidth, TCP is better 'behaved' than UDP in that it will try to limit itself to avoid congestion. UDP does not and hence may actually get more than its fair share of the bandwidth compared to the TCP traffic because of this.