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

From: [email-masked]
Date: Tue, 2 Apr 2002 19:13:53 +0300

Hi again!

> Ivan,
> 
> [email-masked] wrote:
> 
> >         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)...
> 
> 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.

	But there is no way the receiver can know if it is the original DATA chunk or if it has been resent because it was lost in the network... The fact of receiving a TSN that fills a hole might be caused either by packet loss and retransmission, or by reordering... In the second case you have already been sending the SACKs for every DATA chunk previously received and you have not lost the ACK clock... so you might receive more DATA chunks that will trigger the sending of the SACK...

	If the packet was lost, then I don't think that an extra 200ms delay is really that important (since you will drastically lower your sending capabilities in this case). Besides, if the packet was not lost (maybe the SACK was lost, not the DATA chunk), and the data sender is retransmitting, you would normally include just duplicate TSNs in that first SCTP datagram, and thus, the receiver will ack it immediately...

	In any case, I don't think it is a big problem... And in the normal case, SACK delay saves both bandwidth and processing time at the receiver/routers...

	Bye!

	BR Iván Arias Rodríguez

> >         I hope this helps...
> >         BR Iván Arias Rodríguez
> > > Thanks!
> Venkat

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

---

From: [email-masked]
Date: Tue, 2 Apr 2002 22:54:32 +0300

> > Mark thinks its ok to SACK right away IF and only IF you have a
> > gap that is being filled in.
> 
> Almost.
> 
> Mark thinks its OK to SACK immediatly if we are filling in all or
> part of a gap **or** the incoming segment creates or enlarges a gap.

	I guess that you are mostly saying the same, as in the second and third cases (filling part of a gap, or creating a new one), you will end up having gaps, and thus you will send the SACK anyway...

	So the only new case would be that if you had gaps before the receipt of the datagram, no matter if after processing the datagram you don't have them, you must always acknowledge the receipt of those chunks immediately...

	So I think that the basic idea here is that, apart from the case in which you receive only duplicate DATA chunks, you override the delayed SACK rule if before or after processing the DATA chunks you have gaps in your incoming TSN sequence... right?

	BR Iván Arias Rodríguez

> From RFC 2581:
> 
>    Out-of-order data segments SHOULD be acknowledged immediately, in
>    order to accelerate loss recovery.  To trigger the fast retransmit
>    algorithm, the receiver SHOULD send an immediate duplicate ACK when
>    it receives a data segment above a gap in the sequence space.  To
>    provide feedback to senders recovering from losses, the receiver
>    SHOULD send an immediate ACK when it receives a data segment that
>    fills in all or part of a gap in the sequence space.
> 
> allman
> 
> 
> --
> Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
>