Subject: Re: Fast Retransmission in SCTP
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CA+-pjPzogR5VLVOqX0H1jfw-CgB_CDLH1Zc=MAq0qCVoYETq-g@mail.gmail.com>
Date: Fri, 9 Dec 2011 11:34:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B21E99E1-05EC-42DA-A3DF-E91FB207453A@lurchi.franken.de>
References: <CA+-pjPzogR5VLVOqX0H1jfw-CgB_CDLH1Zc=MAq0qCVoYETq-g@mail.gmail.com>
To: Maxim Proshin <mvproshin@gmail.com>
Cc: tsvwg@ietf.org
Precedence: list

On Dec 9, 2011, at 8:27 AM, Maxim Proshin wrote:

> Hi experts,
>=20
> 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:
>=20
> "
> 2.39. Retransmission Policy
>=20
> 2.39.1. Description of the Problem
>=20
> 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].
> "=20
>=20
> Reading this article my first feeling was that fast retransmissions =
should be sent to the same destination where initial transmissions were =
sent.
>=20
> So my first question is=20
>  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.
>=20
> 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.
> "
>=20
> 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=02ts 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.=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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
> "=20
> 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
>=20
> What do you think about this?
>=20
> I'm not sure whether it was discussed already or not. If yes, please =
provide me with discussion's results.
>=20
> --=20
> BR, Maxim