3
$\begingroup$

Is it because it uses 3 way handshaking, it is reliable? Or is it due to other reasons? Like due to congestion control, flow control and error control in TCP? Why do we call TCP as reliable?

$\endgroup$
1
  • $\begingroup$ (Please check the title: protocol or process?) $\endgroup$
    – greybeard
    Jul 23 at 16:12
5
$\begingroup$

TCP is said to be reliable because when an application receives data, it knows that this is exactly the data that the sender sent. No part of the data was lost, reordered, etc.

Error control is the part of TCP that deals with ensuring the reliability of connections. For example, if the sender sends two packets A and B and the receiver received only B, the TCP implementation on the receiver side will wait a little in case A took longer than B to arrive. If A finally arrives, the receiver will release A to the application before B. If A doesn't arrive after a while, the receiver will transmit a request to the sender to retransmit A. (I am simplifying somewhat, see the specification for details.)

This is not related to congestion and flow control. They help the performance of the network, but they aren't needed or helpful to make a connection reliable.

$\endgroup$
3
$\begingroup$

Welcome to CS Stack Exchange!
Unlike UDP, TCP provides reliable message delivery.
To summarize in some points, we can say that:

  • TCP ensures that data is not damaged, lost, duplicated, or delivered out of order to a receiving process, otherwise, it has to recover it.
  • TCP is connection-oriented and enables two-way communication between two endpoints after the three-way handshake.
  • TCP is reliable because the protocol ensures that all data is fully transmitted and can be assembled by the receiver in the correct order.
  • TCP achieves this reliability by assigning a sequence number to each octet it transmits and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within the time-out interval, the data is retransmitted. The TCP retransmission time-out value is dynamically determined for each connection, based on round-trip time. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates. Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments.

For more detailed informations, I suggest you have a look at the specific chapter in the book "Computer Networks" by A. Tanenbaum

$\endgroup$
1
$\begingroup$

Most people call TCP lossless and reliable because of error handling in the protocol.

Every packet exchanged in TCP are sent with a CRC32 hash of the data within. It is trivial to compute a CRC32. It is even more trivial to determine if the CRC32 is the right one after the packet has been sent.

For example here's a document I use as a remainder of how CRC32 are calculated for network. At first I calculate a CRC-8 then I do the CRC32 of the letter I.

CRC: x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1

0001 0000 0100 1100 0001 0001 1101 1011 0111  : Polynomial in binary form
 1     0   4    c    1     1    d    b    7


CRC-8: x8 + x7 + x6 + x4 + x2 + 1

1 0000 0111 : CRC-8 polynomial
I: 0100 1001

0100 1001 0000 0000
1000 0011 1
___________________
1100 1010 1000 0000
1000 0011 1
___________________
0100 1001 0000 0000
 100 0001 11
 __________________
 000 1000 1100 0000
     1000 0011 1
     ______________
     0000 1111 1000
            F    8

E: 0100 0101, result : 0xDC

0100 0101 0000 0000
1000 0011 1
___________________
1100 0110 1000 0000
1000 0011 1
___________________
0100 0101 0000 0000
 100 0001 11
 __________________
 000 0100 1100 0000
      100 0001 11
      _____________
      000 1101 1100
            D    C

I: 0100 1001  CRC-32 of letter I

1001 0010 0000 0000 0000 0000 0000 0000 0000 0000  1)Reverse input bits and 2)append 32 zeros
1111 1111 1111 1111 1111 1111 1111 1111            3)XOR with 32 ones
_________________________________________________
0110 1101 1111 1111 1111 1111 1111 1111 0000 0000  4)Do CRC32 calcs
 100 0001 0011 0000 0100 0111 0110 1101 11         CRC-32 polynomial
 ________________________________________________
 010 1100 1100 1111 1011 1000 1001 0010 1100 0000
  10 0000 1001 1000 0010 0011 1011 0110 111
  _______________________________________________
  00 1100 0101 0111 1001 1011 0010 0100 0010 0000
     1000 0010 0110 0000 1000 1110 1101 1011 1
     ____________________________________________
     0100 0111 0001 1001 0011 1100 1001 1001 1000
      100 0001 0011 0000 0100 0111 0110 1101 11
      ___________________________________________
      000 0110 0010 1001 0111 1011 1111 0100 0100  Remainder
          1111 1111 1111 1111 1111 1111 1111 1111  5)XOR remainder with ones
          _______________________________________
          1001 1101 0110 1000 0100 0000 1011 1011  Result
          1101 1101 0000 0010 0001 0110 1011 1001  6)Reverse result
           D     D    0    2   1     6    B   9   -> What is actually sent with the packet

For TCP there exists several packet types like ACK packets which are used to acknowledge packets have been received. There also exists error packets which should either end a transmission or reset the transmission (make a new handshake etc). TCP is known as a connected protocol as opposed to UDP which is connection-less and can be lossy.

$\endgroup$
0
$\begingroup$

The primary purpose of flow control is to prevent overwhelming the receiver with packets. So imagine the sender is fast and the receiver for whatever reason is slow to process the received data, then using flow control, the receives can slow down the sender. If the receiver would not slow down the sender, eventually the receiver needs to drop packets.

The primary purpose of congestion control is similar to that of flow control. The difference is that the network is the one being protected from overload. Imagine there is a super-fast sender and a super-fast receiver, but with a slow network switch between them, then congestion control will prevent the switch from being overloaded. Overload leads to packet loss.

Packet loss is a problem due to head of line blocking. So you can't process packets that follow after a dropped packet. This leads to a performance degradation in the connection.

Both flow control and congestion control, control the size of the window if inflight data. Effectively the size of the window is the minimum of the congestion window and the receive window.

Flow control and congestion control do not make a TCP connection reliable. The primary purpose is to obtain maximum performance without running into congestion which could eventually lead to congestion collapse if not dealt with correctly.

$\endgroup$

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.