Subject: RE: [Tsvwg] delayed SACK when sender is retransmitting

From: [email-masked]
Date: Tue, 2 Apr 2002 18:48:34 +0300

Hi Venkat!

> -----Original Message-----
> From: ext venkat venkatsubra [mailto:[email-masked]]
> Sent: 01. April 2002 23:51
> To: [email-masked]
> Subject: [Tsvwg] delayed SACK when sender is retransmitting
> 
> 
> Dear All,
> 
> When a receiver receives a retransmitted DATA chunk that advances
> the cumulative TSN Ack number, isn't it good to send the SACK
> immediately
> instead of delaying it ? Otherwise what we see is the sender when
> retransmitting stalling waiting for this SACK before it can proceed
> further.

	But, doing so, you would never delay SACKs at all... When you receive a DATA chunk, either it advances the Cumulative TSN, creates a hole, or it is duplicated... In the last two options, RFC 2960 already states that you cannot delay the SACK...

	And now that I re-read your paragraph above, how can the receiver know that the DATA has been retransmitted? It will know it only if it is duplicated, in which case it will send the SACK (providing no new data is bundled with the duplicated chunk)...

> Since the rfc (2960) requires you to SACK immediately on receiving
> the first DATA chunk, a similar rule could help in case of receiving
> retransmitted DATA chunks i.e. on receiving a DATA chunk that fills a
> hole and advances the cumulative TSN Ack.  Or,  is this left to the
> implementation ?

	This could have also happened due to reordering of packets in the network...

	I think, that in case of a retransmission (due to T3 expiration) the data sender will only send one DATA chunk, a duplicated one, and thus the data receiver will immediately send the SACK you want to receive...

	I hope this helps...

	BR Iván Arias Rodríguez

> Thanks!
> 
> Venkat
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: venkat venkatsubra <[email-masked]>
Date: Tue, 02 Apr 2002 10:02:14 -0600

Ivan,

>         And now that I re-read your paragraph above, how can the receiver know that the DATA has been retransmitted? It will know it only if it is duplicated, in which case it will send the SACK (p…

Receiver need know. For the receiver it is either a retransmitted
or reordered DATA chunk.  But Randall feels delaying the SACK
in both cases is good.

Venkat

---

From: Randall Stewart <[email-masked]>
Date: Tue, 02 Apr 2002 13:12:06 -0600

> or reordered DATA chunk.  But Randall feels delaying the SACK

The trick is that you the receiver can NOT know it was
a retransmit. Mark thinks its ok to SACK right away IF and
only IF you have a gap that is being filled in.

So, for example, one could see the following:

Init-TSN= X

  <------TSN=X+1
  ---->SACK (gap no X)
  <------TSN=X+2
  ---->SACK (gap no X)
  <------TSN=X
  ---->SACK (X fills a hole since X+1 and X+2 are here)-->

Now the trick to this is being able to detect that YES
I have TSN's greater than X when X arrives.

I don't see that if you delay things are hurt either.

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)