* TCP, UDP, IP and packet retransmission
In some recent newsletters, we discussed the inefficiencies caused by the way that typical legacy protocols would “Go-Back-N” whenever there was a lost packet or a packet was received in which there was an error. The basic idea (as a reminder) was that the protocol would go back to the last good packet that was received and then retransmit all packets that followed.
As it turns out, TCP is quite a bit “smarter” than legacy protocols in that TCP – with rare exceptions – will retransmit only the packets that actually were in error. This certainly saves on bandwidth utilization, although in terms of passing information up to the next level there’s little impact because you can’t start processing at the next layer until all of the information has arrived. Thus, the effective delay incurred by losing a packet is essentially a wash whether the subsequent packets are retransmitted or not.
To understand the significance of TCP and its sister protocols, we need first to make sure we’re clear about the functions of each – especially since TCP/UDP/IP do not exactly fit the traditional OSI seven-layer model.
Let’s start with IP. IP has lots of great characteristics that are similar to a legacy “Layer 2” protocol. However, because it is connectionless, there is no fixed connectivity (or virtual circuit) between the source and the destination. Consequently, even though under most circumstances, all packets will follow the same path, this is not a guarantee. And if all packets do not follow the same path, then there is no guarantee that packets will arrive at the destination in the order in which they were sent. Further, unlike the Layer 2 function of some legacy protocols, IP also does not guarantee data delivery. Rather, it’s truly a SNP (Send ‘n Pray) best-effort protocol.
That’s where the function of TCP comes into play. TCP adds a layer of intelligence to guarantee data delivery – assuming that’s what you want. So even though TCP/IP is connectionless at the IP level, TCP adds many of the connection-oriented functions by, among other things, retransmitting data if there is a problem and ensuring that data packets are delivered to the next protocol level in the order in which they were sent.
But you pay a price for that guaranteed delivery. If there is a problem in the delivery, then there’s a delay. That’s a major reason that UDP is used for transporting the payload for VoIP. It’s better to miss a few packets than to incur the delays that TCP would possibly introduce.
Now with this as background, we’re ready for the next couple of newsletters where we’ll delve into exactly how TCP handles selective retransmission, with a little help from some friends.
