Difference between the reliable delivery by link protocols and by TCP

Question

There is a quote I forgot from which network book I copied long time ago.

Some link-layer protocols provide reliable delivery on a link basis, i.e., from transmitting node, over one link, to receiving node. Note that this reliable delivery service is different from the reliable delivery service of TCP, which provides reliable delivery from one end system to another.

We know that TCP is a Transport layer protocol, not a link layer protocol.

I wonder how to understand the difference between the reliable delivery by link protocols and by TCP, as highlighted in bold? Thanks!

Answer 1

Node to node is also known as a hop. Ensuring reliability over one hop and leaving remaining hops in the data path with unknown reliability would be beneficial if that hop was inherently more unreliable, e.g. a wireless link. Wireless protocols such as 802.11 and 802.15.4 (e.g. ZigBee) might have to add Ack/Nak and retry features in order to attain a minimal level of reliability similar to a wired network. Modern wired 802.3 Ethernet using a star configuration is typically quite reliable over one hop even without any Ack/Nak overhead. Wireless on the other hand can be very unreliable, and a reliable link-layer protocol could enhance (or at least not degrade) throughput of a mixed-wired-and-wireless network.

TCP achieves its reliability (in spite of using (unreliable) IP as its underlying protocol) basically by using Ack and Nak responses by the receiver and timeouts on the transmitter to determine if the packet has been delivered. A Nak response or response timeout requires a retransmission of the original packet. Packets are also tagged with sequence numbers to detect missing packets or out-of-order arrival and to perform proper ordering of the received packets.

A link-layer protocol can improve its reliability by employing similar Ack/Nak/timeout techniques. Although having several protocol layers perform this may seem redundant, overall network performance could benefit because the retransmissions (when necessary) would be localized to just the link(s) that had the message failure.

Answer 2

Why there is an (additional) reliability measure needed on an upper level: correctness. Even if there was perfect reliability on the link level, packets could still get lost on the intermediary hosts (overflown queues, crashing routers, etc). Why on the link level: efficiency.

Answer 3

There is no difference in the meaning of "reliable delivery." Regardless of the protocol layer the receiver has to acknowledge receipt of packets and the sender has to retransmit if an ack is not received. There is no reliability without this. The only different is in the layers. TCP has the advantage of running on top of IP, which allows the routing of packets over multiple hops to reach a final destination. At the link layer, the protocols running there only concern themselves with single hops.

Answer 4

"Reliable" does not mean the same thing for everyone. Reliable for TCP means that if you use it on lossy networks or on networks that corrupts and/or reorder packets, then you will not get garbled data, and will essentially receive good data at the end.

The problem is that TCP sucks, and while it works in these cases, it's just horribly slow. So when you use raw TCP on links that regularly loose 0.5% of packets, you will get much less performance than the theoretical data rate of (link_data_rate / (1 - packet loss rate)) on a single link, because of the TCP assumption that all packet loss are caused by congestion.

TCP was designed for networks that seldom loose packets, so TCP only has to tolerate packet loss.

One of the tasks of the reliable link thing on layer two is mainly here to compensate for TCP suckiness. They aren't supposed to be 100% reliable like TCP. For example, 802.11 accept to loose packet if the retransmission count get above a certain threshold, whereas TCP doesn't and will retransmit forever until the application or user decides that it is enough.

The reliable link thing on layer 2 is mainly there for speed. For example, on 802.11, the ack mechanism is also used by nodes so that they can decrease the modulation speed if the wireless link degrades. When 802.11 can't do ACK (e.g. for multicast frames), it typically uses the lowest modulation rate, which is often 1 Mb/s, to get maximum reliability, at the huge expense of speed.

Sometimes, when you have a network with many highly unreliable links, you may need layer 2 reliability, otherwise the whole path may have many unreliable links and the path packet loss rate might get too high to be useful. But this is often not the case on your typical networks.

Historically, TCP picked up because it allowed routers to loose packets. So routers were simpler, faster and the global result was that handling reliability on the endpoints had better performance than handling it in the core network.