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?

  • 2
    The descriptive assumption in your question (IP sends packets on a reliable link-layer) is incorrect for the vast majority of networks today. I personally haven't seen reliable link layers used in over a decade. Even our IBM stuff at work uses plain-ole ethernet now. Commented Feb 28, 2014 at 10:19
  • 2
    Even if the link layer is reliable, how do you know that the router is?
    – JamesRyan
    Commented Feb 28, 2014 at 11:34
  • 2
    And even if the data link is reliable, you cannot be sure that your packet makes it onto the data link. For example: if the outbound interface of a router is overloaded then the router will have no choice but to drop some packets. Commented Feb 28, 2014 at 17:15

3 Answers 3


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.

  • Good points made. Follow up question, why does link layer need to be reliable? Why cant we do away with reliability at link layer and let TCP layer handle retransmissions?
    – karmanaut
    Commented Feb 28, 2014 at 5:13
  • The answer to that question really depends on what protocols are above it. For example, you mention ARQ, which is only used in wireless and V.42 telephone networks, not LAN protocols such as Ethernet, since bit errors are uncommon in short runs of cable. Commented Feb 28, 2014 at 5:16
  • 2
    Furthermore, the data link layer error correction protocols are only relevant for a single segment - a single connection point between two nodes, whereas TCP would be responsible for reliable error-free socket to socket communication that, more often than not, spans many more than just two nodes. Commented Feb 28, 2014 at 5:18
  • @karmanaut, speed. If the link layer detects an error and has a direct feedback channel, asking the MAC on the other side to repeat the last transmission, that is vastly preferable to having the TCP layer wait for ten seconds. Commented Feb 28, 2014 at 13:47

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.

  • Isn't no delivery guarantee by definition unreliable? And for data link layer, I understand that a few tech maybe reliable but my question is that if IP is not bothered about guaranteed delivery, why is link layer making the effort of ARQ to ensure we send reliably?
    – karmanaut
    Commented Feb 28, 2014 at 5:05
  • 4
    As @johnjensen said more eloquently than I, layers are abstractions -- they're just a way of describing functionality. Likewise, ARQ is also an abstraction -- most DL protocols don't have that functionality. Also, you're question seems to imply that whoever designed IP also designed DL protocols. They were developed by many different people at different times for different purposes. A DL protocol that has ARQ functionality (X.25 comes to mind) wasn't designed with IP in mind. In fact it was developed long before IP existed.
    – Ron Trunk
    Commented Feb 28, 2014 at 6:20
  • If you are designing you own set of protocols, then you can put the ARQ functionality wherever it makes most sense. You can choose to follow the OSI model or not (if you did, you'd be the first).
    – Ron Trunk
    Commented Feb 28, 2014 at 6:22

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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