IETF Logo Mail Archive

Re: Query regarding SCTP ordering queue handling.

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Tue, 23 November 2010 07:47 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 CC0F028B797 for <tsvwg@core3.amsl.com>; Mon, 22 Nov 2010 23:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 CoMz5eQEwvZV for <tsvwg@core3.amsl.com>; Mon, 22 Nov 2010 23:47:15 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 99AC628C168 for <tsvwg@ietf.org>; Mon, 22 Nov 2010 23:47:14 -0800 (PST)
Received: from [192.168.1.113] (p508FC6AB.dip.t-dialin.net [80.143.198.171]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 60F271C0B4610; Tue, 23 Nov 2010 08:48:09 +0100 (CET)
Subject: Re: Query regarding SCTP ordering queue handling.
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="windows-1252"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <AANLkTin+ow4bdkV5Z16P1vg1GptC+VRh3Fj6mJbrADBC@mail.gmail.com>
Date: Tue, 23 Nov 2010 08:48:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F21220AC-F297-4DE2-86FF-B64EE1B68D96@lurchi.franken.de>
References: <AANLkTin+ow4bdkV5Z16P1vg1GptC+VRh3Fj6mJbrADBC@mail.gmail.com>
To: sandeep kandula <sandeepkandula30@gmail.com>
X-Mailer: Apple Mail (2.1082)
Cc: tsvwg@ietf.org
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: Tue, 23 Nov 2010 07:47:16 -0000

On Nov 23, 2010, at 8:11 AM, sandeep kandula wrote:
> We have scenario as explained below, please let me know how SCTP has to handle this situation.
> 
> 	• 1.       There is an association established between two nodes (say Node A and Node B) and traffic is flowing between these nodes.
> 	• 2.       Node A sent a data chunk with TSN 25 to Node B. Even though this is complete chunk, due to error at sending side, the B-bit was sent while sending before the checksum is calculated.
> 	• 3.       On reception of chunk (TSN 25) at Node B, it will be keep this chunk in ordering queue as it is expecting the other fragments and will not provide it to SCTP user. Node B will acknowledge the TSN 25 with a SACK.
> 	• 4.       As B-bit was set due to error at Node-A, it will not transmit any other fragment of the packets to Node-B.
> 	• 5.       Node-B will be waiting for infinitely for other fragments of the packets and it will be able to deliver it user.
> Is this the expected behavior of the SCTP at Node-B? If not, can anyone please tell what shall be correct behavior of the SCTP at Node-B? How SCTP can overcome from such situations?
Node B is behaving correctly. To overcome this situation, fix Node A.

Please note, that the situation might change if Node A sends another message.
Then Node B might be able to figure out that Node A is violating the protocol
specification and might (depending on the implementation) send an ABORT. It
might include an error cause indicating a protocol violation.

Best regards
Michael
> 
> Regards,
> V Sandeep Kandula.

v2.23.0 | Report a Bug | By Email