3

So in the networking book by Kurose, we define UDP as a unreliable method because it might not detect errors and therefore transfer a corrupted packet or transfer the data without the order so its not good for important stuff like emails

then it says TCP is a reliable method because it can gurantee data transfer without corruption, and in order, but based on this topic :

https://stackoverflow.com/questions/3830206/can-a-tcp-checksum-fail-to-detect-an-error-if-yes-how-is-this-dealt-with

Something that should be noted here, and that most people overlook completely, is the fact, that the TCP checksum is actually a very poor checksum.

so the checksum of TCP is no good at all?!

so how can TCP be a reliable method when there is a chance that it transfers a corrupted packet and the end system won't notice it? how is this even possible?

because for example i have not received an email with a corrupted message, is it even possible?

  • 3
    TCP is reliable because it guarantees data delivery, in order, not that it guarantees uncorrupted data. A duplicate copy of data as a checksum would be better, but even that could have the same error as the original, and that would waste bandwidth and take too much time. – Ron Maupin Aug 1 '18 at 13:35
  • @RonMaupin so what is the chance of TCP delivering a corrupted data without noticing it? is there any statistic about this? for example do email providers use an application layer corruption checking, or no need for that? – John P Aug 2 '18 at 7:22
6

No checksum is 100% reliable. The more reliable the error detection, the more computational power you need. It's a tradeoff between reliability and speed/processing power.

The TCP checksum was limited by available computing power at the time. It gives you 99.9984% assurance that your data has not been corrupted by single bit errors. The developers assumed that if stricter error checking was required, it would happen at the application layer.

  • So the top answer of that topic i linked is wrong? because he even said the checksum of TCP is very poor! not sure how he consider 99.99% poor, although that topic is from 7 years ago so maybe things have changed i guess – John P Aug 1 '18 at 12:11
  • 1
    "Poor" is in the eye of the beholder. Another reason why opinions are generally discouraged. – Ron Trunk Aug 1 '18 at 12:19
4

So in the networking book by Kurose, we define UDP as a unreliable method because it might not detect errors and therefore transfer a corrupted packet

No, we define UDP as an unreliable protocol because it takes no measures to ensure that the data is actually delivered in the event of problems on the underlying network. It also takes no measures to ensure that the data is delivered in the correct order if the underlying network re-orders packets.

In terms of protection against corruption UDP uses the same checksum that TCP does (technically it's optional but in the vast majority of cases it is used).

so the checksum of TCP is no good at all?!

It depends.

To estimate how likely an application is to experiance corruption we need to answer several questions first.

  1. How much data is being transfered.
  2. What proportion of packets get corrupted in the first place.
  3. Are there lower level checksums? if so how effective are they? (both in terms of the effectiveness of the checksum itself and in terms of whether particular error sources are gaurded by it)
  4. What if any similarities are there between any checksums used by lower layers and the checksum used by TCP. Do these similarities increase the probability of a corrupted packet passing both checks over what would nievely be assumed.

The answers to these questions and hence the probability of corruption will vary massively, from extremely unlikely at one extreme to almost a certainty at the other. People moving a few megabytes of data over high quality networks will get a very different answer than people moving terabytes of data over terrible networks.

  • So even with UDP in 99.99% of times (based on above answer) we never get corrupted data, the difference is that in the case of UDP we just don't get them at all but in TCP we send them again, correct? (so in case of not accepting corrupted packets they are both equal?) – John P Aug 2 '18 at 5:50
  • @JohnP You have to be careful with probabilities to be precise on exactly what probability you are talking about. There is a ~99.99% chance that a TCP checksum will detect an error. However, if you download a file containing gigabytes of data, you could be sending millions of packets and computing millions of checksums. If your IP layer is frequently delivering corrupted data, then it's almost a certainty that the TCP checksum will miss one somewhere. – richardb Aug 2 '18 at 8:11
  • @richardb so its necessary to implement an error detecting method on our application layer if we don't want to receive a corrupt messages, and we can't fully rely on TCP, correct? – John P Aug 2 '18 at 9:17
  • 1
    @John In the end it's a judgement call - if you're a cloud backup provider, I really hope you have strong data integrity checks. For my internal applications, I've not seen a TCP checksum error in the last billion packets, so I'm not losing any sleep over it. As long as you understand that 99.99% is the beginning of the answer not the end, what you do with that information as an application developer is a question for another forum. – richardb Aug 3 '18 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.