When TCP packet is faulty,why retransmit the whole buffer?

Question

Ok so my understanding of TCP is basically like this:

I have this data broken up into packets like [#1,#2,#3,...] that I want to send to Bob. These packets have been wrapped so that the message number is actually included in the packet. So I send out #1,#2,#3,... which are one by one acknowledged by Bob with some delay.

At some point, I've sent packets #n to #n+m, but Bob detects an error with packet #n. He now sends me a message: "back it up and retransmit from n and forward". Upon receiving this, say I've transmitted an additional p packets.

What happens to these m+p packets that are now in the ether? As I understand it, Bob discards them? Why doesn't he just leave a buffer slot open for n and keep receiving the others?

Same question for the sender - what is the reason for retransmitting ALL m+p+1 packets instead of just the #n packet?

Answer 1

For each direction of a conversation, TCP keeps track of the number of bytes sent, and the number of bytes received. This is done using a Sequence number (to track bytes sent) and an Acknowledgement number (to track bytes received).

For simplicity, I'll proceed as if the SEQ# and the ACK# are a count of packets sent (in reality, it is a count of bytes sent). In addition, we will only keep track of the conversation in one direction, we won't bother ourselves with the conversation in the other direction.

Bob                                 Alice
Sends packets #1, #2, #3 --->

Bob sends to Alice packets with SEQ# 1, 2, and 3.... There are three possibilities of how Alice can respond:

• If Alice receives each packet, she will respond with ACK#4, saying she has received everything before #4, and is ready for #4 next.

• If Alice receives only #1, and nothing else, she will respond with ACK#2, indicating she is ready for #2, and has received everything before. This will prompt Bob to sent #2 and #3 again.

• If Alice receives only #1 and #3, and somehow #2 gets lost in transit. Alice still has no choice but to respond with ACK#2. Remember, Alice can only respond with an Acknowledgement number that confirms the packets she has received. If she responded with #4, it would communicate to Bob that #1, #2, and #3 were received, which isn't the case.

So in both cases prior, Bob receives ACK#2, and Bob has no way of knowing whether just #2 or #2 and #3 were lost -- so to play it safe, Bob will resend #2 and #3.

That said, in the 3rd case above, when Bob re-sends #2 and #3, but Alice already had #3.. whether she replaces the bytes within packet #3 in her buffer with the newly received #3, or whether she simply ignores the duplicate received #3 is entirely up to the implementation -- and largely the difference will be unnoticeable to the user. The end effect is the same.

---

Of course, this is simply a factor of there just being two numbers being tracked, A SEQ# stating bytes sent, and an ACK# tracking bytes received. As the OP pointed out, there was a feature added to TCP called Selective Acknowledgement, or TCP SACK.

TCP SACK allows the receiver to not just send an ACK# (bytes received), but to also specify a "left edge" and "right edge" of the bytes that were received. Which then indicates to the sender specifically which bytes need to be resent.

Answer 2

First an important concept in networking is the product of bandwidth and latency. This determines how many packets need to be "in flight" at once for full utilisation. In general this figure has grown over the years as bandwidth has increased massively while latency has remained roughly the same (pesky speed of light limits)

Traditionally TCP only acked continguous received data. I do not know for sure why it was done this was but I would guess simplicity was the driving force.

This left a sender with two options. It could resend a single packet and wait for a response from the receiver or it could resend a bunch of packets and possiblly end up sending duplicates.

I expect that in the early internet this was not much of a problem. The bandwidth-delay products were relatively small and waiting a round trip time for each lost packet was probablly not too big a deal.

As bandwidth increased this became more of an issue and after experiments in the late 80s and early 90s TCP shared acknowlagements were standardised in RFC2018 in 1996 .