Reliablity vs unreliable service at IP and Link Layer

Question

I am taking about the 5 layer model. It is well documented that TCP is a reliable service and IP is best-effort delivery and hence unreliable (ref RFC 792 - TCP). Also, the data link layer is 'reliable' because of its ARQ mechanism guaranteeing sequential delivery of packets (ref).

I cannot make sense of sending packets of reliable service (TCP) on a lower unreliable service (IP) which in turn sends packets on a layer which provides reliability (Link Layer). Why can't we do away with reliability at link layer as IP is unreliable?

Answer 1

The issue is that you're operating under the notion that each layer is in and of itself a separate, autonomous entity. Understand that IP is not the only packet delivery protocol in existence, it just happens to be the most common one. Also understand that these "layers" are simply abstraction tools - the take away is that each "layer" is dependent on the one beneath it for some functions, and the layers further down the stack can hand off certain duties (ie reliable data transmission) to the layers above them when appropriate to keep overhead low and performance high. Each lower layer encapsulates data sent from the layers above it on its way down to the wire, and the lower layers decapsulate the data on the way back up the stack to the application.

The paper you linked about the data link layer even states that while its delivery mechanisms are intended to be reliable, they are still best effort, and there is an assumption made that higher layer protocols (ie TCP) will handle retransmission if necessary.

Answer 2

If you look at the class notes, you'll see that #4 says, "perhaps." Some data link technologies are reliable, most are not. The reasons are mostly historical, as many technologies were created for voice and then re-purposed for data. The reason we leave guaranteed delivery to higher layers is that many applications don't require it, and to put it in a lower level adds overhead where it isn't useful.

Answer 3

TCP uses special rules to make IP Reliable, even though it would otherwise be unreliable.

It seems you're looking for more of a conceptual understanding, so I'm going to give an example without actually referring to the true inner workings of TCP.

Say you and I were chatting on a Two-way Radio (or Walkie Talkie). I can hit the transmit button and say something, but I have no way to make sure you received anything. In this example, the Walkie-Talkie is "IP" -- an unreliable protocol.

Say you and I decided to do something above and beyond IP, and employed the following rules when using our Two-way Radios:

1. Whenever I finish speaking, I say "over"
2. Whenever you hear me say "over", You repeat back to me the first word and the last word I said (before "over")
3. Whenever I hear you acknowledge my first and last words, I will say "acknowledgement received"
4. Once you hear "acknowledgement received", you are then free to speak on the radio.

If at anytime, one of us does the above but doesn't hear the expected response after 5 seconds, we repeat the last thing we said.

These "set of rules" are effectively what TCP calls for. In following these rules, we can make what would otherwise be an unreliable communication medium (Two-Way Radio / IP), a reliable communication method (TCP).

So as others have said, the "unreliability" of IP does not negate the "reliability" of TCP. TCP simply uses IP with smart acknowledgements to make communication using TCP/IP reliable. TCP by itself can not handle sending packets from one host to another, all it can do is apply certain rules to an 'end to end' delivery scheme (like IP), to make that delivery scheme more reliable.

Hope this helps.