Subject: Fast Retransmission in SCTP

From: Maxim Proshin <[email-masked]>
Date: Fri, 9 Dec 2011 11:27:23 +0400

Hi experts,

here I would like to discuss the Fast Retransmission algorithm in RFC 4960.
Frankly this RFC does not describe clearly how to send (to which
destination) fast retransmissions but we can find some information in RFC
4460 which says:

"
*2.39. Retransmission Policy

2.39.1. Description of the Problem

The current retransmission policy (send all retransmissions an
alternate destination) in the specification has performance issues
under certain loss conditions with multihomed endpoints. Instead,
fast retransmissions should be sent to the same destination, and only
timeout retransmissions should be sent to an alternate destination [4].*
"

Reading this article my first feeling was that *fast retransmissions should
be sent to the same destination where initial transmissions were sent*.

So my first question is
 *is my RFC interpretation correct or not?*

Meanwhile, there are some more articles about retransmision policies where
RFC's authors also participated. For instance, "Retransmission Policies
With Transport Layer Multihoming" describes some improvements in fast
retransmission policy in respect to RFC 2960 and I think that they were
considered during RFC 4960 preparation. This analysis also proposes to send
fast retransmissions to the same destination:
"
*In this solution, all retransmissions are sent to the*
*same destination as their original transmissions.*
*...*
*Instead of all*
*retransmissions following the Retransmit to Same Destination*
*policy of Solution 1, only Fast Retransmissions*
*should follow this policy.*
"

It seems that this statement confirms my initial feeling described above.
But at the same time it says about primary path:
"
*Using the same destination for retransmissions has*
*the added advantage that the primary destination's cwnd*
*benets from successful retransmissions.*
"
and it results is some doubts. On the one hand fast retransmissions should
be sent to the same destination, on the other it should be sent to the
primary destination.
In usual case "the same" and primary destinations are equal. But RFC 4960
doesn't prevent primary destination changing by the user so it can be
changed in run-time.

So my second question is
 *if the primary destination is changed in run-time, where SCTP should sent
fast retransmissions which were detected for the previous primary
destination?*

The mentioned above article describes one advantage in respect to sending
to the primay destination, this is about cwnd benets from successful
retransmission. But I think that in case of fast retransmission it will not
be observed or the advantage is very very low.

At the same time sending to the primary destination results in a big
disadvantage: SCTP should recalculate cwnd if it sends fast retransmissions
to the primary destination because RFC 4960 says:
"
When a Fast Retransmit is being performed, the sender SHOULD ignore the
value of cwnd
"
I think the reason is that it was considered during initial transmission.

*What do you think about this?*

I'm not sure whether it was discussed already or not. If yes, please
provide me with discussion's results.

-- 
BR, Maxim

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 9 Dec 2011 11:34:34 +0100

On Dec 9, 2011, at 8:27 AM, Maxim Proshin wrote:

> Frankly this RFC does not describe clearly how to send (to which destination) fast retransmissions but we can find some information in RFC 4460 which says:
> 
> "
> 2.39. Retransmission Policy
> 
> timeout retransmissions should be sent to an alternate destination [4].
> " 
> 
> Reading this article my first feeling was that fast retransmissions should be sent to the same destination where initial transmissions were sent.
> 
> So my first question is 
>  is my RFC interpretation correct or not?
Yes. Fast retransmissions should be send to the same destination as the initial transmission.
Timer based retransmissions should use an alternate destination.
> 
> Meanwhile, there are some more articles about retransmision policies where RFC's authors also participated. For instance, "Retransmission Policies With Transport Layer Multihoming" describes some improvements in fast retransmission policy in respect to RFC 2960 and I think that they were considered during RFC 4960 preparation. This analysis also proposes to send fast retransmissions to the same destination:
> "
> In this solution, all retransmissions are sent to the
> same destination as their original transmissions.
> ...
> Instead of all
> retransmissions following the Retransmit to Same Destination
> policy of Solution 1, only Fast Retransmissions
> should follow this policy.
> "
> 
> It seems that this statement confirms my initial feeling described above. But at the same time it says about primary path:
> "
> Using the same destination for retransmissions has
> the added advantage that the primary destination's cwnd
> benets from successful retransmissions.
> "
> and it results is some doubts. On the one hand fast retransmissions should be sent to the same destination, on the other it should be sent to the primary destination. 
> In usual case "the same" and primary destinations are equal. But RFC 4960 doesn't prevent primary destination changing by the user so it can be changed in run-time.
> 
> So my second question is
>  if the primary destination is changed in run-time, where SCTP should sent fast retransmissions which were detected for the previous primary destination?
Changing the primary is normally not done at a high rate. So you are looking at the
case where fast retransmission occur and the user changed the primary in between.

I guess there is no special case on the RFC for that. So the fast retransmission would
go to the destination to which it was initially sent. The same applies if the user
specified a destination and therefore the primary was not used.
> 
> The mentioned above article describes one advantage in respect to sending to the primay destination, this is about cwnd benets from successful retransmission. But I think that in case of fast retransmission it will not be observed or the advantage is very very low.
> 
> At the same time sending to the primary destination results in a big disadvantage: SCTP should recalculate cwnd if it sends fast retransmissions to the primary destination because RFC 4960 says:
> "
> When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd
> " 
If you do a fast retransmit, you assume that the packet has left the network.
So you would have to subtract and add it. This means ignoring...

Best regards
Michael
> 
> What do you think about this?
> 
> I'm not sure whether it was discussed already or not. If yes, please provide me with discussion's results.
> 
> -- 
> BR, Maxim

---

From: Maxim Proshin <[email-masked]>
Date: Sun, 11 Dec 2011 11:36:58 +0400

Hi Michael,

Thank you! You confirmed my initial feeling that FR should not be based on
the primary destination and now it is clear.
Regarding your last answer I think you meant that sending FR to the same
destination we should not change cwnd because adding and substraction means
ignoring. But if FR were based on the primary destination we would have to
recalculate it in case "the same" and primary destinations would be
different.

BR, Maxim

2011/12/9 Michael Tüxen <[email-masked]>

> > Reading this article my first feeling was that fast retransmissions
> should be sent to the same destination where initial transmissions were
> sent.
> >
> > So my first question is
> > Meanwhile, there are some more articles about retransmision policies
> where RFC's authors also participated. For instance, "Retransmission
> Policies With Transport Layer Multihoming" describes some improvements in
> fast retransmission policy in respect to RFC 2960 and I think that they
> were considered during RFC 4960 preparation. This analysis also proposes to
> send fast retransmissions to the same destination:
> > "
> > It seems that this statement confirms my initial feeling described
> above. But at the same time it says about primary path:
> > "
> > bene ts from successful retransmissions.
> > "
> > and it results is some doubts. On the one hand fast retransmissions
> should be sent to the same destination, on the other it should be sent to
> the primary destination.
> > In usual case "the same" and primary destinations are equal. But RFC
> 4960 doesn't prevent primary destination changing by the user so it can be
> changed in run-time.
> >
> > So my second question is
> >  if the primary destination is changed in run-time, where SCTP should
> sent fast retransmissions which were detected for the previous primary
> destination?
> > The mentioned above article describes one advantage in respect to
> sending to the primay destination, this is about cwnd benets from
> successful retransmission. But I think that in case of fast retransmission
> it will not be observed or the advantage is very very low.
> >

-- 
BR, Max

---

From: Michael Vittrup Larsen <[email-masked]>
Date: Wed, 21 Dec 2011 13:55:38 +0100

I don't believe this is a correct interpretation of the articles from Armando 
et. al ([4] of RFC4460).  I believe the correct interpretation is

  "fast retransmissions should be sent to the destination to which
   we currently are sending data"

Note that this is not the same as "...to the same destination where initial 
transmissions were sent" in case of current primary path failovers.  In fact, 
if we send fast retransmissions "...to the same destination where initial 
transmissions were sent" we may in fact be sending these on a path different 
from where we currently are sending data - and this is exactly (to my 
understanding) what the change in SCTP fast retransmission in RFC4960 is all 
about.

To see why we need to look behind the words used by RFC4960 and into the 
articles and the reasoning in the articles:

1) Sending fast retransmissions (FR) on a path different from where we 
currently are sending new data may be subject to excessive RTO values on the 
alternative path. Successful FRs do not update the RTT of the alternative path 
due to Karns algorithm and the RTO on the alternative path is therefore 
conservative for the majority of the association and sending FRs on such a 
path is not optimal.

2) FRs do not benefit the cwnd of the path where we are sending new data but 
instead the cwnd of the alternative path, which is less attractive.

3) Possible timeouts of FRs sent on the alternative path will delay cwnd 
increments on the path where we are sending new data. Since these timeouts are 
conservative the delay may be excessive.

Neither [4] nor RFC4960 explicitly in text describes the FR policy in case 
where a change of the current primary data transfer path has occurred. But in 
essence the above reasoning/discovery of [4] clearly dictates what the correct 
interpretation should be.

Regards,
Michael

On Friday, December 09, 2011 11:34:34 Michael Tüxen wrote:
> > here I would like to discuss the Fast Retransmission algorithm in RFC
> > 4960. Frankly this RFC does not describe clearly how to send (to which
> > destination) fast retransmissions but we can find some information in
> > RFC 4460 which says:
> > 
> > "
> Yes. Fast retransmissions should be send to the same destination as the
> initial transmission. Timer based retransmissions should use an alternate
> destination.
> 
> > Policies With Transport Layer Multihoming" describes some improvements
> > in fast retransmission policy in respect to RFC 2960 and I think that
> > they were considered during RFC 4960 preparation. This analysis also
> > proposes to send fast retransmissions to the same destination: "
> > But at the same time it says about primary path: "
> > should be sent to the same destination, on the other it should be sent
> > to the primary destination. In usual case "the same" and primary
> > destinations are equal. But RFC 4960 doesn't prevent primary destination
> > changing by the user so it can be changed in run-time.
> > 
> > So my second question is
> > 
> Changing the primary is normally not done at a high rate. So you are
> looking at the case where fast retransmission occur and the user changed
> the primary in between.
> 
> I guess there is no special case on the RFC for that. So the fast
> retransmission would go to the destination to which it was initially sent.
> The same applies if the user specified a destination and therefore the
> primary was not used.
> 
> > retransmission. But I think that in case of fast retransmission it will
> > not be observed or the advantage is very very low.
> > 
> > disadvantage: SCTP should recalculate cwnd if it sends fast
> > retransmissions to the primary destination because RFC 4960 says: "
> > value of cwnd "
> If you do a fast retransmit, you assume that the packet has left the
> network. So you would have to subtract and add it. This means ignoring...
> 
> Best regards
> Michael
> 

-- 
*****************************************************************************************
Michael Vittrup Larsen
Software Architect
 
Tieto Denmark A/S
IP Solutions, Telecom & Media
Skanderborgvej 232, 8260 Viby J, DK-Denmark
Direct Phone / Mobile +45 3091 8469
E-mail: [email-masked]
*****************************************************************************************
www.tieto.com  
 
Please note: The information contained in this message may be legally 
privileged and confidential and protected from disclosure. If the reader of 
this message is not the intended recipient, you are hereby notified that any 
unauthorised use, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify us 
immediately by replying to the message and deleting it from your computer. 
Thank You.