Subject: [Tsvwg] fast retransmit in SCTP Implementors Guide

From: Benedict Rainer <[email-masked]>
Date: Tue, 12 Feb 2002 17:29:39 +0100

Hello SCTP experts,

when checking our current SCTP implementation for compatibility with the
implementors guide some questions concerning fast retransmit or SACK
processing arose:

What happens, when a SACK contains no 'HighestTSNinSack', i.e. it doesnt ack
new data, but the receiver reneges some chunks previously acked by not
including them in the SACK?

According to M2 I would not qualify the reneged chunks as 'Stray DATA
chunks',
but I guess the actions 6.2.1 D) iii) (mark as missing, start T3 if not
running, see below) must be taken.
Otherwise a deadlock situation could occur, because for the sender the
reneged chunks are already acked and are not subject for retransmission,
neither after timeout nor for fast retransmit.

In many situation this would probably clear if RWND grows by such an amount,
that the receiver can send 4 SACK that ack new chunks and so the transmitter
can  use all the information from the sack, but I'm not sure if this is
always true.

What was the reason for introducing M1-M5, especially 'HighestTSNinSack'?

Any comments welcome

best regards
Rainer

SCTP Implementors Guide,
   M2) Each time a SACK arrives reporting 'Stray DATA chunk(s)' record
       the highest TSN reported as newly acknowledged, call this
       value 'HighestTSNinSack'. A newly acknowledged DATA chunk is one
       not previously acknowledged in a SACK.

       When the SCTP sender of data receives a SACK chunk that
       acknowledges, for the first time, the receipt of a DATA chunk,
       all the still unacknowledged DATA chunks whose TSN is older than
       that newly acknowledged DATA chunk, are qualified as
       'Stray DATA chunks'.

RFC2960,
6.2.1 D) Any time a SACK arrives, the endpoint performs the following
         ...
         iii) If the SACK is missing a TSN that was previously
         acknowledged via a Gap Ack Block (e.g., the data receiver
         reneged on the data), then mark the corresponding DATA chunk as
         available for retransmit:  Mark it as missing for fast
         retransmit as described in Section 7.2.4 and if no retransmit
         timer is running for the destination address to which the DATA
         chunk was originally transmitted, then T3-rtx is started for
         that destination address.

---

From: Janardhan Iyengar <[email-masked]>
Date: Tue, 12 Feb 2002 16:10:26 -0500 (EST)

Hi Rainer,

> What happens, when a SACK contains no 'HighestTSNinSack', i.e. it
> doesnt ack new data, but the receiver reneges some chunks previously
> acked by not including them in the SACK?

As per the RFC/Imp Guide, the TSN should get marked for FR after 4
missing reports. Consider the following case:

1 ------>
2 ------>
3 ---X
4 ------>
5 ------>

1 <-----
2 <-----
2 (4-4) <-----
2 (4-5) <-----

At this point, 3 has been struck twice. Now the receiver renegs on TSN4

2 (5-5) <----

Now, TSN4 gets struck once. 3 more SACKs striking TSN4 will cause FR.

> chunks', but I guess the actions 6.2.1 D) iii) (mark as missing, start
> T3 if not running, see below) must be taken. Otherwise a deadlock
> situation could occur, because for the sender the reneged chunks are
> already acked and are not subject for retransmission, neither after
> timeout nor for fast retransmit.
>
> In many situation this would probably clear if RWND grows by such an
> amount, that the receiver can send 4 SACK that ack new chunks and so
> the transmitter can use all the information from the sack, but I'm not
> sure if this is always true.
>

AFAIK, the FR algo in the Implementor's guide protects from a few out of
order TSNs from incorrectly causing FR. Consider:
1 --->
2 --->
...
8 --->

Suppose that somehow 8 got ahead of all the TSNs, then according to the FR
algo, TSN 8 would cause a SACK of 0(8-8), TSN 1 through 7 would cause
SACKs of the form 1(8-8), 2(8-8), 3(8-8)... "HighestTSNinSACK" for these
SACKs will be 1, 2, 3 respectively.

In such a case, using the RFC's FR algo, 3(8-8) would cause an FR of TSNs
4-7, but using the Implementor guide's FR algo, no FR would occur.
HighestTSNinSACK helps implement this modification

I don't know if I answered your question completely.. hope that clarifies
things though.

regards,
jana

-----------------------------------------------------------------------
Janardhan R. Iyengar				   [email-masked]
University of Delaware		       http://www.cis.udel.edu/~iyengar
-----------------------------------------------------------------------

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