IETF Logo Mail Archive

Query regarding CONFIRMED address behaviour in SCTP RFC

Nagesh <nageshs@huawei.com> Mon, 23 August 2010 14:49 UTC

Return-Path: <nageshs@huawei.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997453A6885 for <tsvwg@core3.amsl.com>; Mon, 23 Aug 2010 07:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.995
X-Spam-Level:
X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA3ixObQ4I0P for <tsvwg@core3.amsl.com>; Mon, 23 Aug 2010 07:49:55 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 409F33A689C for <tsvwg@ietf.org>; Mon, 23 Aug 2010 07:49:55 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7M00A5G17RSR@szxga03-in.huawei.com> for tsvwg@ietf.org; Mon, 23 Aug 2010 22:50:16 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7M00CMV17RMT@szxga03-in.huawei.com> for tsvwg@ietf.org; Mon, 23 Aug 2010 22:50:15 +0800 (CST)
Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7M003DW17Q8A@szxml04-in.huawei.com> for tsvwg@ietf.org; Mon, 23 Aug 2010 22:50:15 +0800 (CST)
Date: Mon, 23 Aug 2010 20:20:15 +0530
From: Nagesh <nageshs@huawei.com>
Subject: Query regarding CONFIRMED address behaviour in SCTP RFC
To: tsvwg@ietf.org
Message-id: <4832DF4F0954419397F0F12E92648901@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_J+W389idHcyG1glbUYwYEg)"
Thread-index: ActC0n8kab/d5b6JSzOMAnQXhf9jdQ==
Cc: 'prasad' <prasadkumbala@huawei.com>, rajithr@huawei.com
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 23 Aug 2010 14:49:56 -0000

Hi Group,
	Greetings. I have a doubt regarding SCTP RFC 4960, section 5.4, it
mentions that any messages should always be sent on the CONFIRMED address
but sending message on UNCONFIRMED address is optional.

	Especially, in the following scenario the association may not be
established, if stack does not implement sending on CONFIRMED address.

	Scenario as below:

Client				Server
------------------------------------------
IP1				IP3

IP2				IP4


	Message sequence as below:
INIT -> IP1 -> IP3
INIT-ACK -> IP3 -> IP1
COOKIE-ECHO -> IP1 -> IP3
After sending COOKIE-ECHO, IP1 goes down, 
COOKIE-ACK -> IP3 -> IP1 is lost
Retransmit COOKIE-ECHO -> IP2 -> IP3
COOKIE-ACK -> IP3 -> IP1 (Reply is always to CONFIRMED address).

Then even after many retransmissions, server will always send COOKIE-ACK to
IP1 (sending only to CONFIRMED address), so finally INIT.MAX.RETRANS is
reached and association gets aborted.

	So, my question is, why sending COOKIE-ACK on UNCONFIRMED address is
OPTIONAL behavior.  Please let me know, if I am missing something here.

Thanks and Regards,
Nagesh.

v2.23.0 | Report a Bug | By Email