Subject: timeout issue question

From: Patricio Barletta <[email-masked]>
Date: Sun, 13 Jul 2003 14:26:56 -0300

We are using the ns-2 to test some issues in sctp and we're experiencing 
some strange behaviour we want to clarify.
The scenario is the following: 5 consecutive data chunks (one per 
packet) are being dropped. One of them is retransmitted by timeout, then 
it is fast retransmitted some milliseconds after (When the 
restransmision by timeout happens, we receive the forth consecutive 
missing for the TSN being retransmitted, and then it is fast retransmitted).

Is this the expected behaviour ?
Should the number of missing reports be reset after a TSN is 
retransmitted by timeout ? This is not clear in the RFC neither the 
impl. guide (v8)

Regards,
Patricio.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 13 Jul 2003 16:16:54 -0600

Patricio,

I set the FR count to 4 when marking for RTO retransmission.  This makes
the chunk no longer eligble (ever) for FR.

But, I am curious: You can surely not be using anywhere near the
recommended RTO value, or you have a real high latency network, correct?
How is it that 4 SACKs take longer than RTO to be returned?

I stumbled on the effect when setting RTO.Min to 0.

It might not be in the RFC or the IG, but I remember it being discussed
that after a RTO retransmission, there is no such thing as fast recovery,
just RTO, and that chunks after RTO were no longer eligibel for FR.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Patricio Barletta <[email-masked]>
Date: Sun, 13 Jul 2003 20:39:03 -0300

As far as i can see in the simulation code, whenever a chunk is 
retransmited by timeout, it is not marked as ineligible for FR.
I didn't change the RTO value and the network delay is 200ms.
Some of the duplicates that arrive for that chunk are received before 
the timeout retransmission takes place.

Patricio.

---

From: Patricio Barletta <[email-masked]>
Date: Mon, 14 Jul 2003 11:29:41 -0300

Patricio.

Patricio,

--brian

Regards,
Patricio.

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Mon, 14 Jul 2003 10:50:03 -0400 (EDT)

> the timeout retransmission takes place.

I am curious how this could happen. It doesn't seem possible. You are
saying that the same TSN is retransmitted by an RTO, and later the same
TSN is fast rtx'd? How does the ack for the retransmitted TSN trigger a
fast rtx for itself? This _could_ be a bug in our code, but I would be
interested in seeing a more detailed descriptiong of the problem before I
go hunting down the bug. Can you describe in detail (ie, timeline) the
problem scenario?

Thanks...

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0

---

From: Patricio Barletta <[email-masked]>
Date: Mon, 14 Jul 2003 22:17:32 -0300

I could reproduce it using the "Example Script 1" in sctp.README, 
dropping 5 consecutive packets. (In my case i dropped packets 5,6,7,8,9, 
one data chunk per packet)

3 missing reports for TSN #5 are received just before the retransmission 
by timeout, at almost the same time the forth missing report is 
received, and then TSN #5 is "fast retransmitted"

Hope this helps.
Patricio.

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Tue, 15 Jul 2003 14:41:35 -0400 (EDT)

I am sorry, but I cannot reproduce your problem. If you drop packets 5-9,
how are you able to get 3 missing reports for TSN 5. That would mean that
you have succesfully transmitted TSNs 10-12, which your cwnd shouldn't
allow.

Let's take this discussion offline. Please send me your TCL script. Also,
what version of our SCTP module are you using?

~armando

0--                                                  --0

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Tue, 15 Jul 2003 18:23:47 -0400 (EDT)

Patricio,

Thanks for the TCL script that you sent. I now see the problem, and have
realized that it is a bug in our code. The fix will be in the next release
(3.4), but if you want to make the change now you only have to add one
line of code.

In void SctpAgent::TimeoutRtx(SctpDest_S *spDest),

change:
--------------
      if(spCurrNodeData->spDest == spDest &&
	 spCurrNodeData->eGapAcked == FALSE &&
	 spCurrNodeData->eAdvancedAcked == FALSE)
	{
	  MarkChunkForRtx(spCurrNodeData);
	}
-----------

to:
-----------
      if(spCurrNodeData->spDest == spDest &&
	 spCurrNodeData->eGapAcked == FALSE &&
	 spCurrNodeData->eAdvancedAcked == FALSE)
	{
	  MarkChunkForRtx(spCurrNodeData);
	  spCurrNodeData->eIneligibleForFastRtx = TRUE;
	}
-----------

~armando

0--                                                  --0

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 18:36:48 -0600

Armando,

That's what I do too.  But I can't remember why.  Did it come from some
discussion or is it stated in the RFC or IG somewhere?

--brian

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 17 Jul 2003 00:01:05 -0400 (EDT)

> discussion or is it stated in the RFC or IG somewhere?

I'm glad you asked this, because Jana just pointed out to me that
_technically_ it wasn't a bug. The RFC nor the IG say to do this, but it
_should_ be done. The IG says that after a TSN is FR'd, that TSN is
ineligible for another FR. The text should actually say that the TSN
should be ineligible after an FR and/or timeout.

I think this change should go into the IG. Does everyone agree?

~armando

0--                                                  --0

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 22:13:37 -0600

Armando,

> I think this change should go into the IG. Does everyone agree?

Yes, I agree, we better say it explicitly somewhere.

--brian

---

From: Patricio Barletta <[email-masked]>
Date: Thu, 17 Jul 2003 10:31:26 -0300

i agree.

Armando,

--brian

~armando

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 18 Jul 2003 16:40:54 -0500

Armando/all:

The orginal problem with multiple FR's was
you did not want to keep FR'ing the same thing multiple times.. but
in the case of a timeout... you would have "cleared the pipe" so I don't
see it a problem, after a T-3 that you FR...

I.e:

Tmit(TSN1)---------->

<--4 sakc/strikes
----FR(TSN1)------------->
....
T3-Timeout
-----Retran TSN1---------->
..<A>

At point <A> the pipe is empty.. so it should be more than
safe to do

<----4 sack/strikes

-------FR(TSN1)---------->

and possibly repeat the timeout assuming of course that you can
ever reach a point where you send out enough new data to get
a FR...

Remember the thing we did not want (with the FR wording) was

------FR(TSN1)------------>
<---4 sacks--------
------FR(TSN1)------------>
<---4 sacks-------
-----FR(TSN1)------------>

Since the sacks may all be in the pipe .. i.e. a very big cwnd allows
100 segments out.. you may have 50 out-of-order sacks on your
way to you after you realize a FR and send your FR... You don't want any 
other FR's
until the timeout.. but after the time-out the pipe should be clean and if
you somehow recognize a FR situation then it should be ok to do a 
subsequent.

Note this does not take into acount the CACC issues that Jana as raised 
in hte
past and I do need to think about that too.. but for the moment I think
a subsequent FR after a timeout shoudl be ok.. but of course once the 
subsequent
FR is done until the next T3 you could not do yet another FR :>

R

-- 

Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 18 Jul 2003 15:50:45 -0600

Randall,

So are you saying one should (could) set the count to 0 on T3
retransmit instead of to, say, 4?

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 18 Jul 2003 17:35:16 -0500

>retransmit instead of to, say, 4?

Yep.. I don't see why not.. the purpose in the  IG was to keep
you from getting all the sack's yet in the pipe when you did the FR
and doing multiple FR's again and again..

Once you hit a T3 you can reset the counter and count FR again.. if you
could ever get that many new segments out.. I don't see how that would
happen .. still not clear on this.. but I don't see that it shoudl be 
prohibited.. by the
time you take the T3 the pipe shoudl be clear..

R

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 21 Jul 2003 12:34:53 -0700

> ever reach a point where you send out enough new data to get

I guess the issue, which many people are discussing in the
tsvwg mailing list, is that what if spurious timeout happens
(even with retransmission to the same destination)?

> FR is done until the next T3 you could not do yet another FR :>

It seems to me that there is really not much gain to allow
FR after a timeout.  It only helps when the timeout retransmission
is also dropped.  If that happens, the network is really
congested and it is good for SCTP to wait for another timeout.
I guess SCTP implementors should be more conservative in this
case.

-- 

						K. Poon.
						[email-masked]