Subject: T3-rtx timer and fast retransmit

From: Vlad Yasevich <[email-masked]>
Date: Tue, 22 Apr 2008 11:27:26 -0400

I am trying to figure out if our implementation of fast retransmit is
correct and have a question about the meaning of the following:

  4)  Restart the T3-rtx timer only if the last SACK acknowledged the
      lowest outstanding TSN number sent to that address, or the
      endpoint is retransmitting the first outstanding DATA chunk sent
      to that address.

Specifically, what's is meant by the "first outstanding DATA chunk".

Is it the very first DATA chunk that was ever sent to the destination, or
is it the first chunk that is still outstanding?

Thanks
-vlad

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 22 Apr 2008 14:31:51 -0400

Vlad -

I believe it is the first unacknowledged chunk that needs to be
retransmitted.

Regards,
Lincoln 

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Tuesday, April 22, 2008 11:27 AM
To: SCTP Implementors
Subject: T3-rtx timer and fast retransmit

Is it the very first DATA chunk that was ever sent to the destination,
or is it the first chunk that is still outstanding?

Thanks
-vlad

---

From: Randall Stewart <[email-masked]>
Date: Wed, 23 Apr 2008 07:34:47 -0700

> is it the first chunk that is still outstanding?
Basically when you recognize one or more fast retransmits need to be
done. That first one you enter "fast recovery".

During this time you do your retransmits and do NOT cut the cwnd
if you see say another 3 strikes and mark something else.

You exit fast recovery when the SACK shows up for the first
one you recognized.

The idea is you don't take more than 1 cwnd hit per window
of data (cwnd of data that is) that has been sent.

In TCP they call this fast recovery too if memory serves me correct.

In our implementation in BSD when we first hit a FR we mark a flag
that we are in FR-recovery mode. And also which TSN will exit us.

When we get the ack for that, we clear the FR-Recovery flag. We also
do not cut the cwnd on that destination. Note that FR-Recovery
flag is a per destination flag...

Does that help?

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 23 Apr 2008 11:21:26 -0400

> flag is a per destination flag...

Hi Randy

The question I have is wrt T3-timer during fast recovery.  Specifically,
the scenario is the following:

DATA1 ---->
DATA2 (lost)
DATA3 ---->
DATA4 ---->
      <---- SACK (CTSN=1)
DATA5 ---->
      <---- SACK (CTSN=1, GAP3)
      <---- SACK (CTSN=1, GAP4)
      <---- SACK (CTSN=1, GAP5)
DATA2 (fast-rtx, lost)

So, the primary question is, do we reset the T3-timer when we fast retransmit
DATA2.   The timer would already be running from the time the first SACK arrived.

Right now, lksctp does not.  We changes to not retransmit data that was sent less then
rto ago, we end up in a situation when the DATA2 was fast retransmitted shortly before
t3-timer expired and since it was sent less then rto ago, we do not send it.  As that's
the only packet that would have been sent, we send nothing and as a result do not
reset T3-timer and never retransmit DATA2 again.

So, it makes sense to restart T3-rtx timer when fast retransmitting the lowest outstanding
TSN, but there are 2 different interpretations of the point I quoted above.  So, I am
looking for clarification.

-vlad

---

From: Randall Stewart <[email-masked]>
Date: Wed, 23 Apr 2008 08:30:39 -0700

> looking for clarification.

Yes, restarting the T3 is appropriate in my opinion.. and it is
what we do in BSD... give the association a bit more time
to get all the data and get the sack's back :-)

R

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 28 Apr 2008 13:22:19 -0400

Hi Randy

One more question about Fast-rtx and BSD implementation.

It looks like you allow a chunk to be fast retransmitted multiple
times if you keep getting strikes for it after the first fast
retransmission.

Michael pointed out to linux folks text to from 2960/4960 that
says that we should fast-retransmit a given chunk only once, and
we changed the code to conform the the spec.

Can you point me at the paper that recommends multiple fast
retransmits?

Thanks
-vlad

---

From: Randall Stewart <[email-masked]>
Date: Mon, 28 Apr 2008 14:32:24 -0400

> times if you keep getting strikes for it after the first fast

Yes, we do that ONLY when we do NOT FR to an alternate
destination. This is a switch in the code that turns that on/off

> we changed the code to conform the the spec.

Again, you can only do multiple FR's if and only if you do NOT change
the destination address when you do a FR.

Otherwise it will cause problems... thats what the restriction
is against.. doing a FR to an alternate address...

R

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 28 Apr 2008 20:50:08 +0200

Hi Vlad,

using fast retransmitting TSN multiple times is considered in
http://www.armandocaro.net/publications/2004.globecom.acaro.pdf
It has not made it into RFC 4960, however it is also not forbidden
to do it (There are no MUST NOT in the RFC).

 From my personal point of view it does not make sense to multiply
fast retransmit a TSN within a time which corresponds to the RTO
calculation before doing the [RTO.Min, RTO.Max] computation.
Retransmitting earlier looks like forward error correction, since
you can not expect a SACK to be received before RTT.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Mon, 28 Apr 2008 16:31:19 -0400

Michael:

There are ways to do this without worrying about the time..

What we do is:

A) Store the TSN where strikes count.. so lets say we
     send TSN 1... we store 1 with it.

B) When we hit the FR when SACK saying cum=0, gap 2-4, we
     do the FR but we also record the next to send TSN with TSN1,
     so if the next one was 6, we mark that in TSN1.

C) Now when we get a gap ack the TSN must be greater than 6 before
     we can consider striking it.. Again when we reach 3 strikes..  ACK of
     TSN 9, we do a subsequent FR.

This only is enabled of course if we are not sending a FR to the alternate
destination (if multi-homed)..

R

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 29 Apr 2008 17:10:55 +0200

Hi Randy,

yes,  that does make sure that you do not fast retransmit
before it can be received. You can base that on TSN, not
on time as I indicated.

This procedure is not blindly doing multiple fast retransmits
on every three gap reports and is not specified in any RFC. It
is a BSD specific extension.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Tue, 29 Apr 2008 16:52:21 -0400

> is a BSD specific extension.

And also documented in several papers that Armando, Jana,Paul
and I worked on I think.. cant remember precisely which one though :-)

R

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 30 Apr 2008 08:23:22 +0200

> and I worked on I think.. cant remember precisely which one though :-)
True, I send a link to the paper a couple of days ago to the list...

Best regards
Michael