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

  • The ACK acknowledges everything that came before, so an ACK for anything subsequent to 3 covers it.
    – Ron Maupin
    Jun 4 '19 at 20:36
  • What I meant with 4, 5 receive their ACK is that it receives SACK 2 | 4,5 Jun 4 '19 at 20:55
  • 1
    "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 '19 at 20:59
  • Hi Cioby. If an ACK for #2 is received and the window size is 10 "packets", this puts packets 3-12 within the window and eligible to be sent -- even if no other ACK's are received. Remember, the Window Size does not affect how often ACK's are sent, only how many "packets" can be sent unacknowledged. This answer has details of how ACKnowledgement numbers work, and this answer has details on how SACK works. They might help fill in more context of ACK's and SACK's.
    – Eddie
    Jun 4 '19 at 21:58
  • Eddie, 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? Jun 6 '19 at 10:42
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
               Ack 3  w=10
 3 lost
       Ack 3, Sack 4-4 w=10
       Ack 3, sack 4-5 w=10

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:

  1. 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.

  2. 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.

  3. 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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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