Fast Retransmission in SCTP

Maxim Proshin <mvproshin@gmail.com> Fri, 09 December 2011 07:27 UTC

Return-Path: <mvproshin@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FBE11E808C for <tsvwg@ietfa.amsl.com>; Thu, 8 Dec 2011 23:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPnT7kE-B2cn for <tsvwg@ietfa.amsl.com>; Thu, 8 Dec 2011 23:27:24 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0192D11E808B for <tsvwg@ietf.org>; Thu, 8 Dec 2011 23:27:23 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so3971701wgb.13 for <tsvwg@ietf.org>; Thu, 08 Dec 2011 23:27:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=lFfB4uE4EwGnwFsZEF/byBotklbFKkTzoIXfboeKNj0=; b=UXPtQaTc/+aaN06ykQp3wkmktdCUdgUJzPrJ3IoMtwPMl9yoB5+xhgEa18To+97Z6F QAwIBSV/aaffLpORodIIEWqYMepUk3wKVnSTxEAnxugy6e/gqZdIiAKmj1cwle8HgSE6 K0CFGd19upNXiPl3irgwyEk2d9XlW8pjf/rac=
MIME-Version: 1.0
Received: by 10.180.102.233 with SMTP id fr9mr9471361wib.40.1323415643182; Thu, 08 Dec 2011 23:27:23 -0800 (PST)
Received: by 10.216.173.69 with HTTP; Thu, 8 Dec 2011 23:27:23 -0800 (PST)
Date: Fri, 09 Dec 2011 11:27:23 +0400
Message-ID: <CA+-pjPzogR5VLVOqX0H1jfw-CgB_CDLH1Zc=MAq0qCVoYETq-g@mail.gmail.com>
Subject: Fast Retransmission in SCTP
From: Maxim Proshin <mvproshin@gmail.com>
To: tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="f46d04451a274d566904b3a3b71b"
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2011 07:27:25 -0000

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