Packet Loss and Packet duplication

Question

I am trying to find out what the difference between packet loss and packet duplication problems is. Does anyone know what 'packet duplication' is all about? Is it the same as re-transmitting packets when a loss is detected in TCP?

Solution 1

No. In TCP delivery of "packets" is reliable(I think the term data should be better in this case, since it's a stream oriented protocol).

Packet loss and duplication are problem related to unreliable protocols datagram oriented like UDP. In UDP when you send a datagram this could arrive duplicated, out of order or even don't arrive at all.

Is it the same as re-transmitting packets when a loss is detected in TCP?

Yes and no. Let's say that TCP uses internally an ack mechanism to detect missing data, and automatically retrasmit them. So the missing data are trasparent to the user, and handled by the protocol itself.

Does anyone know what 'packet duplication' is all about?

In certain situations could happen that IP packets are duplicate along the path to their destination. For example a router could decide to forward incoming traffic thorugh 2 different network interfaces. In this case could happen that both IP packets will reach the destination.

TCP handle duplicated IP packets problem, so you don't care about them.

UDP doesn't handle them. When you receive a datagram it's not guaranteed that you didn't have received the same datagram before. You should check it.

Solution 2

There are two things you could mean be duplicate packets: duplication of the payload (the data being sent) or an exact duplicate of the payload and headers. TCP will attempt to resend data that it doesn't receive an ACK (acknowledgement from the receiver that the packet arrived okay) for. However, this leads to the famous "two Generals" problem where you can never be sure of the data actually arrived, or if you just didn't get the ACK because the ACK packet was lost. The receiver could have gotten the packet, replied with an ACK, but the ACK was then lost. In this case, the sender will assume the packet was never received, and send another packet with the same payload duplicated. Because of this case, protocols like TCP need to handle getting the data sent multiple times. In this case the answer is, "yes", they're the same thing.

The second thing duplicate packets could mean an actual 100% duplicate packet (payload and headers). This could happen because of errors in software, hardware, or routing problems or misconfigurations. In this case no, it's a somewhat different problem than TCP intentially sending new packets with duplicate payload from detection of packet loss. In this case the sender only sent one packet, but it was duplicated somewhere along the way by routers or hardware interfaces.

Comments

[PherricOxide]

Delivery is never guaranteed, you just have reasonable knowledge that the delivery happened or failed.

[Heisenbug]

@PherricOxide: you're right. I changed it with reliable, should sound better right?

[Sergey Ushakov]

@Heisenbug: do you know of any real-world router solutions that might decide to forward incoming traffic through two different network interfaces? we are seeking such a solution...

[rindeal]

@s-n-ushakov eg. iptables with TEE target support can do this

[Jan Hudec]

Saying TCP is "reliable", without qualification, is wrong. It isn't, because it can't be, and assuming it is is dangerous. There are real world protocols that are broken because of not realizing this. TCP guarantees each packet will arrive only once and it guarantees order (so in this context the answer is correct), but if the connection breaks, you don't know what exactly arrived. You only know up to some point everything did (what was acknowledged), but with operating systems not reporting that to the applications it's not much use anyway.

[J Freebird]

Do you know how TCP or any other protocol deals with two Generals problem? That is how TCP handles duplicated packets?