Subject: a question about SCTP fast recovery algo.

From: Ilknur Aydin <[email-masked]>
Date: Mon, 20 Sep 2004 15:50:18 -0400 (EDT)

Hello all:

I need help on understanding what should happen during fast recovery,
especially with cwnd and ssthresh values.

Section 2.8 of implguide10.txt (which I currently use) says "... while in
fast recovery, the ssthresh and cwnd SHOULD NOT change for any
destinations."

The events that cause changes in cwnd and ssthresh are:

(1) t3_rtx_timer expires --> ssthresh = max(cwnd/2, 2*mtu), cwnd = 1*mtu
(2) another fast rtx --> ssthresh = max(cwnd/2, 2*mtu), cwnd = ssthresh
(3) sack processing --> ssthresh remains the same, cwnd changes according
to slow start or cong. avoidance based on some other criteria (like cwnd
was in full use, cumAckPoint increased by the sack, etc).
(4) cwnd degrade timer expires --> halve the cwnd, since the dest. is not
in use.

I handled case (3) above; that is, if assoc. is in fast recovery I prevent
an incoming sack to change the cwnd of the dest addrs. For case (4) I did
not do anything yet, but it seems I should not let any change in cwnd
values either ?? Also, I am not sure how to handle case (1) and (2).

For case (1), should I freeze t3_rtx timers and cause the timers not to
expire during fast recovery (which probably does not make sense) ?? Or let
the timers expire, do rtx of the chunks, but do not change cwnd and
ssthresh values ? Or let the timers expire, exit fast recovery phase,
change cwnd and ssthresh, and do rtx of the chunks??

And for case (2), even though there are new fast rtxes during fast
recovery (this should be possible,?), I should not change ssthresh and
cwnd ??

One of the scenarios I try is as follows:

- Sender S and receiver R are both single homed
- initial cwnd value is 4380 bytes, according to 2.30 of implguide10.txt
- mtu is 1500 bytes
- 10 data chunks of size 1000 each are sent
- chunks 101, 106, 107, 108, 109 are dropped (to create the scenario)

After 4th sack, 101 is fast rtxed and assoc. enters to the fast recovery,
where fast recovery exit point is tsn 109.

Below picture shows how my implementation is working currently. ???
marks show the points where I am not sure what to do exactly.

	Sender S		Receiver R
cwnd=4380
	---100------------------->
	---101------------------->X
	---102------------------->
	---103------------------->
	---104------------------->(cwnd could be exceeded up to 1*mtu)
	<---SACK for 102---------
cwnd=5880
	---105------------------->
	---106------------------->X
	---107------------------->X
	<---SACK for 103---------
	---108------------------->X
	<---SACK for 104---------
	---109------------------->X
	<---SACK for 105---------
ssthresh=3000
cwnd=3000
enter fast recovery,recover=109
do fast rtx of 101
	|---fast rtx 101--------->
	<---SACK for rtxed 101------
still in fast recovery
because only
[101-105] is acked
	.
	.
	.
eventually t3_rtx_timer
expires
ssthresh=1500(???)
cwnd=1500 (???)
mark all the current
outstanding chunks
(i.e. 106, 107, 108, 109)
for rtx, but assoc.
is still in fast recovery???
	---rtx 106------------------->
	<---SACK for rtxed 106------
	---rtx 107------------------->
	<---SACK for rtxed 107------
	---rtx 108------------------->
	<---SACK for rtxed 108------
	---rtx 109------------------->
	<---SACK for rtxed 109------
since [101-109] is acked
exit fast recovery eventually.

I would appreciate any comments/explanations/pointers.

best regards,

Ilknur Aydin
DEGAS Networking Group
Dept. of Computer and Information Sciences
University of Delaware
http://www.cis.udel.edu/~aydin

---

From: Janardhan Iyengar <[email-masked]>
Date: Mon, 20 Sep 2004 18:26:20 -0400 (EDT)

Hi Ilknur,

> (4) cwnd degrade timer expires --> halve the cwnd, since the dest. is not

[...]

> change cwnd and ssthresh, and do rtx of the chunks??

I am not sure what the correct behavior here should be, but I think that
the cwnd should be reduced (set to 1MTU) when a timeout occurs, no matter
what. So in this case, I think the sender should let the timer expire, set
the cwnd to 1MTU at expiration, and exit fast recovery - after a timeout,
most things are just reset. (I'm trying to think of a scenario other than
loss of a fast rtx that could cause a timeout during fast recovery..)

> recovery (this should be possible,?), I should not change ssthresh and

Yes, that is the idea with fast recovery - multiple rtxs within the same
window will not cause the window to reduce multiple times.

> cwnd=1500 (???)

I think so. If not, there will be a burst of rtxs later on when the ack
for the first timeout retransmission is received.

> 	<---SACK for rtxed 106------

If cwnd was not set to 1MTU earlier at the timeout, this ack would allow
for 3 rtxs to go out. I'm not sure if this is bad, but is
certainly not conservative.

regards,
jana

---

From: Randall Stewart <[email-masked]>
Date: Tue, 21 Sep 2004 06:29:30 -0400

Hmm..

I think that this wording needs to be changed.. and its
a sad that I just sent off version 11 yesterday :-o

I think that that sentence should only apply to 2 and 3
I think... not 1 for sure and probably not 4 since
the "if you don't use it you loose it" principle still
applies even when you are in FR.

Now one other question I have on this, is why other destinations
cannot increase.. thinking on this more.. is why other destinations
should not increase....

If for some reason the ULP switches primary's to some other
destination why not let it grow if its eligible for
growing?

It cannot grow if the cum-ack does not move, thats already
present in the base spec... so the only way you will
grow is if the fast recovery is somewhere above the
cum-ack point but NOT at it.

Probably a very unlikely thing if one thinks about it.. so
the restriction most likely for growth will never happen.

Hmm... its probably not so big of deal.. but we do
need to clearify that 1/4 reductions are still
going to happen.

R

-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222