pipelining procedure for fast retransmit

pipelining procedure for fast retransmit

by Leo Mattéo Litrico -
Number of replies: 1

Hello,

I am a bit confused about which pipelining procedure we are using when talking about fast retransmit. It seems as if we are using go-back-n, since in the lecture example we are recieving duplicate ACKs for a segment, and we consider the segments of greater seg number as unACKed, however I don't seem to catch on at what point we retransmit those unACKed segements, since in the lecture video "reno" we seem to retransmit seg 300 (segment that was lost), and straight after seg 700. Does the sender simply assume that segments 400 to 600 were received without having to receive an ACK for them (but doesn't this violate the go-back-n procedure) and also if this is the case, what happens if two segements were lost instead of one (eg seg 300 and seg 500) how would we know which ones the receiver received?

Thank you very much, Leo Litrico

  

In reply to Leo Mattéo Litrico

Re: pipelining procedure for fast retransmit

by Katerina Argyraki -

Hi Leo,

Fast retransmit is a technique used by TCP, which is neither fully go-back-N nor fully selective repeat.

TCP has features from each family:

  • It has selective ACKs (and this is why fast retransmit makes sense, as you point out).
  • But it retransmits only a single segment (whenever it retransmits). 

In the particular example you mention, the sender does not assume that segments 400 to 600 were received. It assumes that *maybe* they were received, and that's why it quickly retransmits 300. But it confirms that they were received once it gets ACK 700.

Now, what happens when both 300 and 500 are lost? In the particular example, Alice's window is 400, which means that she sends only 4 segments at a time (400 unacknowledged bytes). As a result, if two segments are lost, Alice will not get 3 duplicate ACKs, and she will not do a fast retransmit. She will simply timeout waiting for an ACK that acknowledges that Bob received seg 300.