Re: Fast Retransmission in SCTP

[Maxim Proshin <[e-mail]>]

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 <[e-mail]>

> On Dec 9, 2011, at 8:27 AM, Maxim Proshin wrote:
>
> > 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?
> 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
> > 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?
> 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
> > "
> > I think the reason is that it was considered during initial transmission.
> 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
>
>


-- 
BR, Max