TCP Packet Loss

[statty01]

Hi,

I would like to verify something with respect to TCP as I am not that familiar with the protocol.

If I have two sources sending TCP traffic, one with large traffic and the other with low traffic. If the larger source is experiencing difficulties in transmitting packets due to the large size of the data and I drop packets from the smaller source, will this help the larger source to send more traffic?It is my understanding that with TCP a packet loss makes a source slow down, hence if the smaller source slows down then the larger source might be able to transmit more data? Can someone clarify this for me please?

Also, with UDP, if a packet is dropped it does not have the same effect as TCP - if a packet is dropped it is simply dropped - is this case?

What if I had a combination of a TCP source and UDP source, would there be an affect on the other sender if a packet was dropped? I am assuming not?

 

[Noway2]

TCP has an algorithm that is used to dynamically update the MTU, maximum transmission unit, or as you put it packet size. If packets are getting dropped, corrupted, or otherwise no good, the algorithm will attempt to reduce the packet size to increase the odds that the packet will make it through.

I don't recall the rules of the algorithm and I remember reading that they are not simple and involve many variables.

UDP, unlike TCP does not make a best effort to get the packet through. If it is dropped, it is dropped. When using UDP, which has advantages in some circumstances, it is up to the application to apply the necessary error checking and re-transmission.

 

[burtsbees]

If I have two sources sending TCP traffic, one with large traffic and the other with low traffic. If the larger source is experiencing difficulties in transmitting packets due to the large size of the data and I drop packets from the smaller source, will this help the larger source to send more traffic?"

No---if the larger source has trouble sendng data due to congestion, assuming that is what you are asking, then the destination is only concerned with that flow---the other source has nothing to do with it.

Are you assuming that the sender of the large data has output buffers that are being filled too fast? If this is the case, the destination does not drop packets from another source to help the larger flow source. The problem in this case would be the source, and you can even shut the other connections down---the problem will still be there, at the first source.

Now if the larger source is having trouble because it is filling the destination's buffers, the window size is renegotiated by means of congestion avoidance algorithms, etc. This is actually the entire purpose of the "slow-start" in TCP---to guarantee as best as it can the transmission. Problems with transmissions are discovered early, at the start, and therefore are dealt with accordingly.

Capisce?

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[statty01]

Thank you for your replies. It is much clearer now.
I am not assuming that the sender of the large data has output buffers that are being filled too fast. I am looking at the sharing of excess bandwidth between TCP aggregates. If a larger service subscriber drops a packet then the TCP congestion mechanism reduces its sending window size, hence the large aggregate takes time to recover its original sending rate. During this time a smaller subscriber has more access to the excess bandwidth and hence grabs as much of it as it can. I am looking at ways of overcoming this.

 

[burtsbees]

You may be referring to congestion collapse. Here may be a helpful PDF...

http://ica1www.epfl.ch/PS_files/LEB3132.pdf

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!