I will ask the question based on the following scenario. Assume I have to send 10 packets using TCP using a window size of 5. I send 1, 2 and receive ACK for them, I send 3 and the ACK is lost, I send 4, 5 and receive their ACK. My question is: having SACK negotiated, does TCP continue transmitting outside the window? I.e. It starts transmitting 6 before receiving 3? That in the case that the window doesn't shift
9
-
The ACK acknowledges everything that came before, so an ACK for anything subsequent to 3 covers it.– Ron Maupin ♦Jun 4, 2019 at 20:36
-
What I meant with 4, 5 receive their ACK is that it receives SACK 2 | 4,5– Cioby AndreiJun 4, 2019 at 20:55
-
2"The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received."– Ron Maupin ♦Jun 4, 2019 at 20:59
-
1Eddie, assume we don't have SACK, for a window size of 5, packet 3 doesn't receive ACK, what packets have to wait for ACK of 3?– Cioby AndreiJun 6, 2019 at 10:42
-
1@CiobyAndrei Putting aside that ACK/SEQ#'s are a reference to bytes sent, not packets, if the window size is 5, the sender can send 1-5 without getting any acknowledgement from the receiver. The receiver will attempt to send an ACK every other received packets (Delayed Acknowledgement), which means after packet #2 arrives, the receiver will send ACK#3, implying everything before #3 was received. The sender can now send packets 3 thru 7 without further acknowledgement (the "window" of 5 packets moves forward to enable #3-7).– EddieJun 6, 2019 at 17:30
|
Show 4 more comments
2 Answers
no, SACK will not move the beginning of the sender window (also called SND.UNA)
Let's consider that the receiver has receiver buffer of size 5. If the receiver has received packets 4 and 5 but not 3, his receiver buffer will look like: [space for 3, packet 4, packet 5, space for 6 and 7]. He can't deliver 4 and 5 to application and can't move its window. Thus there is no point for the sender to move its window and send anything past 6 and 7 (see note 1 below).
However note:
when you receive an ACK for one, the window will shift, so 6 can be sent; the same applies to ACK for two and 7.
if you send the packet three, it gets delivered but the ACK is lost, then when you send the packet 4, TCP will ACK 4 (normal cumulative ACK) indicating that all packets up to 4 are delivered. You don't need SACK for this.
having a TCP with constant window is a very simplified situation that never happens. TCP will employ congestion control, which will change the size of window. In particular TCP Reno and NewReno will utilize fast recovery which can change the size of the window past 5. It can use the SACK fields to determine how to change the size of the window. (of course provided that the receiver window is not exceeded)
Seq+len must be < ACK+WIN
No you can't empty data in sack, (TCP is Sequential)
And it doesn't fill the window either
1
2
Ack 3 w=10
3 lost
4
Ack 3, Sack 4-4 w=10
5
Ack 3, sack 4-5 w=10
